On Thu, Oct 23, 2014 at 08:44:09AM +0200, Jan Kiszka wrote: > On 2014-10-22 22:34, Benjamin Herrenschmidt wrote: > > On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote: > >> I thought about this again, and I'm not sure anymore if we can use > >> ACPI > >> to "black-list" the incompatible virtio devices. Reason: hotplug. To > >> my > >> understanding, the ACPI DRHD tables won't change during runtime when a > >> device shows up or disappears. We would have to isolate virtio devices > >> from the rest of the system by using separate buses for it (and avoid > >> listing those in any DRHD table) and enforce that they only get > >> plugged > >> into those buses. I suppose that is not desirable. > >> > >> Maybe it's better to fix virtio /wrt IOMMUs. > > > > I always go back to my initial proposal which is to define that current > > virtio always bypass any iommu (which is what it does really) and have > > it expose via a new capability if that isn't the case. That means fixing > > that Xen thingy to allow qemu to know what to expose I assume but that > > seems to be the less bad approach. > > Just one thing to consider: feature negotiation happens after guest > startup. If we run a virtio device under IOMMU control, what will we > have to do when the guest says it does not support such devices? Simply > reject operation? > > Jan We could restrict this to the new set of device IDs that got introduced in virtio 1.0. That actually has a mechanism for devices to gracefully reject a combination of features if we still need it. > -- > Siemens AG, Corporate Technology, CT RTC ITP SES-DE > Corporate Competence Center Embedded Linux -- 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
