From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH RFC 00/11] qemu: towards virtio-1 host support Date: Thu, 23 Oct 2014 08:44:09 +0200 Message-ID: <5448A3B9.4050400@siemens.com> References: <1412692807-12398-1-git-send-email-cornelia.huck@de.ibm.com> <54349246.6000905@amacapital.net> <20141008110428.6fc78115.cornelia.huck@de.ibm.com> <20141022084438.GA8051@redhat.com> <5447BC84.1010402@siemens.com> <1414010056.364.20.camel@pasglop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1414010056.364.20.camel@pasglop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Benjamin Herrenschmidt Cc: thuth@linux.vnet.ibm.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Andy Lutomirski , virtualization@lists.linux-foundation.org List-Id: virtualization@lists.linuxfoundation.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhC8S-0000Vb-Rk for qemu-devel@nongnu.org; Thu, 23 Oct 2014 02:44:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhC8L-000316-Bx for qemu-devel@nongnu.org; Thu, 23 Oct 2014 02:44:36 -0400 Received: from thoth.sbs.de ([192.35.17.2]:57628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhC8L-000312-1l for qemu-devel@nongnu.org; Thu, 23 Oct 2014 02:44:29 -0400 Message-ID: <5448A3B9.4050400@siemens.com> Date: Thu, 23 Oct 2014 08:44:09 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1412692807-12398-1-git-send-email-cornelia.huck@de.ibm.com> <54349246.6000905@amacapital.net> <20141008110428.6fc78115.cornelia.huck@de.ibm.com> <20141022084438.GA8051@redhat.com> <5447BC84.1010402@siemens.com> <1414010056.364.20.camel@pasglop> In-Reply-To: <1414010056.364.20.camel@pasglop> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 00/11] qemu: towards virtio-1 host support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: thuth@linux.vnet.ibm.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Andy Lutomirski , Cornelia Huck , virtualization@lists.linux-foundation.org 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