qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH RFC 00/11] qemu: towards virtio-1 host support
Date: Thu, 23 Oct 2014 08:44:09 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]