On 2014/6/25 15:55, Paolo Bonzini wrote:
Il 25/06/2014 09:34, Chen, Tiejun ha scritto:
On 2014/6/25 14:48, Paolo Bonzini wrote:
Second problem. Your IGD passthrough code currently works with QEMU's
PIIX4-based machine. But what happens if you try to extend it, so that
Yes, current xen machine, xenpv, is based on pii4, and also I don't
known if we will plan to migrate to q35 or others. So its hard to
further say more now.
it works with QEMU's ICH9-based machine? That's a more modern machine
that has a PCIe chipset and hence has its ISA bridge at 00:1f.0. Now
But even in this case, could we set the real vendor/device ids for that
ISA bridge at 00:1f.0? If not, what's broken?
The config space layout changes for different vendor/device ids, so the
guest firmware only works if you have the right vendor/device id.
Paolo,
After I discuss internal, we think even we just set the real
vendor/device ids to this ISA bridge at 00:1f.0, guest firmware should
still work well with these pair of real vendor/device ids.
So if you think something would conflict or be broken, could you tell us
what's exactly that? Then we will double check.
Thanks
Tiejun
It is only slightly better, but the right solution is to fix the driver.
There is absolutely zero reason why a graphics driver should know
about the vendor/device ids of the PCH.
This means we have to fix this both on Linux and Windows but I'm not
sure if this is feasible to us.
You have to do it if you want this feature in QEMU in a future-proof way.
You _can_ provide the ugly PIIX4-specific hack as a compatibility
fallback (and this patch is okay to make the compatibility fallback less
hacky). However, I don't think QEMU should accept the patch for IGD
passthrough unless Intel is willing to make drivers
virtualization-friendly. Once you assign the IGD, it is not that
integrated anymore and the drivers must take that into account.
It is worthwhile pointing out that neither AMD nor nVidia need any of this.
The right way could be to make QEMU add a vendor-specific capability to
the video device. The driver can probe for that capability before
Do you mean we can pick two unused offsets in the configuration space of
the video device as a vendor-specific capability to hold the
vendor/device ids of the PCH?
Yes, either that or add a new capability (which lets you choose the
offsets more freely).
If the IGD driver needs config space fields of the MCH, those fields
could also be mirrored in the new capability. QEMU would forward them
automatically.
It could even be a new BAR, which gives even more freedom to allocate
the fields.
looking at the PCI bus. QEMU can add the capability to the list, it is
easy because all accesses to the video device's configuration space trap
to QEMU. Then you do not need to add fake devices to the machine.
In fact, it would be nice if Intel added such a capability on the next
generation of integrated graphics, too. On real hardware, ACPI or some
Maybe, but even this would be implemented, shouldn't we need to be
compatible with those old generations?
Yes.
- old generation / old driver: use 00:1f.0 hack, only guaranteed to work
on PIIX4-based virtual guest
- old generation / new driver: use 00:1f.0 hack on real hardware, use
capability on 00:02.0 on virtual guest, can work on PCIe virtual guest
- new generation / old driver: doesn't exist
- new generation / new driver: always use capability on 00:02.0, can
work on PCIe virtual guest.
Paolo
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
