Re: [Qemu-devel] [PATCH RFC 00/11] qemu: towards virtio-1 host support

["Michael S. Tsirkin" <mst@redhat.com>]

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