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. Paolo > * 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 > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
