Re: [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

From: Paolo Bonzini
Date: Fri Dec 05 2014 - 08:03:44 EST

On 05/12/2014 09:50, Gerd Hoffmann wrote:
> A few comments on the kernel stuff (brief look so far, also
> compile-tested only, intel gfx on my test machine is too old).
> * Noticed the kernel bits don't even compile when configured as
> module. Everything (vgt, i915, kvm) must be compiled into the
> kernel.

I'll add that the patch is basically impossible to review with all the
XenGT bits still in. For example, the x86 emulator seems to be
unnecessary for KVMGT, but I am not 100% sure.

I would like a clear understanding of why/how Andrew Barnes was able to
do i915 passthrough (GVT-d) without hacking the ISA bridge, and why this
does not apply to GVT-g.


> * Design approach still seems to be i915 on vgt not the other way
> around.
> Qemu/SeaBIOS bits:
> I've seen the host bridge changes identity from i440fx to
> copy-pci-ids-from-host. Guess the reason for this is that seabios uses
> this device to figure whenever it is running on i440fx or q35. Correct?
> What are the exact requirements for the device? Must it match the host
> exactly, to not confuse the guest intel graphics driver? Or would
> something more recent -- such as the q35 emulation qemu has -- be good
> enough to make things work (assuming we add support for the
> graphic-related pci config space registers there)?
> The patch also adds a dummy isa bridge at 0x1f. Simliar question here:
> What exactly is needed here? Would things work if we simply use the q35
> lpc device here?
> more to come after I've read the paper linked above ...
> cheers,
> Gerd
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at