From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion Date: Tue, 10 Nov 2015 11:27:33 +0100 Message-ID: <20151110102733.GJ2255@suse.de> References: <20151109133624-mutt-send-email-mst@redhat.com> <1447109937.31884.42.camel@kernel.crashing.org> <1447121076.31884.61.camel@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <1447121076.31884.61.camel@kernel.crashing.org> 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 List-Archive: List-Post: To: Benjamin Herrenschmidt Cc: linux-s390 , KVM , "Michael S. Tsirkin" , Sebastian Ott , "linux-kernel@vger.kernel.org" , Andy Lutomirski , Christian Borntraeger , Christoph Hellwig , Andy Lutomirski , sparclinux@vger.kernel.org, Paolo Bonzini , Linux Virtualization , David Woodhouse , "David S. Miller" , Martin Schwidefsky List-ID: On Tue, Nov 10, 2015 at 01:04:36PM +1100, Benjamin Herrenschmidt wrote: > The "in absence of the new DT binding" doesn't make that much sense. > = > Those platforms use device-trees defined since the dawn of ages by > actual open firmware implementations, they either have no iommu > representation in there (Macs, the platform code hooks it all up) or > have various properties related to the iommu but no concept of "bypass" > in there. > = > We can *add* a new property under some circumstances that indicates a > bypass on a per-device basis, however that doesn't completely solve it: > = > =A0 - As I said above, what does the absence of that property mean ? An > old qemu that does bypass on all virtio or a new qemu trying to tell > you that the virtio device actually does use the iommu (or some other > environment that isn't qemu) ? You have the same problem when real PCIe devices appear that speak virtio. I think the only real (still not very nice) solution is to add a quirk to powerpc platform code that sets noop dma-ops for the existing virtio vendor/device-ids and add a DT property to opt-out of that quirk. New vendor/device-ids (as for real devices) would just not be covered by the quirk and existing emulated devices continue to work. The absence of the property just means that the quirk is in place and the system assumes no translation for virtio devices. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Date: Tue, 10 Nov 2015 10:27:33 +0000 Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion Message-Id: <20151110102733.GJ2255@suse.de> List-Id: References: <20151109133624-mutt-send-email-mst@redhat.com> <1447109937.31884.42.camel@kernel.crashing.org> <1447121076.31884.61.camel@kernel.crashing.org> In-Reply-To: <1447121076.31884.61.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Benjamin Herrenschmidt Cc: linux-s390 , KVM , "Michael S. Tsirkin" , Sebastian Ott , "linux-kernel@vger.kernel.org" , Andy Lutomirski , Christian Borntraeger , Christoph Hellwig , Andy Lutomirski , sparclinux@vger.kernel.org, Paolo Bonzini , Linux Virtualization , David Woodhouse , "David S. Miller" , Martin Schwidefsky On Tue, Nov 10, 2015 at 01:04:36PM +1100, Benjamin Herrenschmidt wrote: > The "in absence of the new DT binding" doesn't make that much sense. >=20 > Those platforms use device-trees defined since the dawn of ages by > actual open firmware implementations, they either have no iommu > representation in there (Macs, the platform code hooks it all up) or > have various properties related to the iommu but no concept of "bypass" > in there. >=20 > We can *add* a new property under some circumstances that indicates a > bypass on a per-device basis, however that doesn't completely solve it: >=20 > =A0 - As I said above, what does the absence of that property mean ? An > old qemu that does bypass on all virtio or a new qemu trying to tell > you that the virtio device actually does use the iommu (or some other > environment that isn't qemu) ? You have the same problem when real PCIe devices appear that speak virtio. I think the only real (still not very nice) solution is to add a quirk to powerpc platform code that sets noop dma-ops for the existing virtio vendor/device-ids and add a DT property to opt-out of that quirk. New vendor/device-ids (as for real devices) would just not be covered by the quirk and existing emulated devices continue to work. The absence of the property just means that the quirk is in place and the system assumes no translation for virtio devices. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752429AbbKJK1m (ORCPT ); Tue, 10 Nov 2015 05:27:42 -0500 Received: from mx2.suse.de ([195.135.220.15]:57864 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752073AbbKJK1j (ORCPT ); Tue, 10 Nov 2015 05:27:39 -0500 Date: Tue, 10 Nov 2015 11:27:33 +0100 From: Joerg Roedel To: Benjamin Herrenschmidt Cc: Andy Lutomirski , Andy Lutomirski , David Woodhouse , "linux-kernel@vger.kernel.org" , "David S. Miller" , sparclinux@vger.kernel.org, Christian Borntraeger , Cornelia Huck , Sebastian Ott , Paolo Bonzini , Christoph Hellwig , KVM , Martin Schwidefsky , linux-s390 , Linux Virtualization , "Michael S. Tsirkin" Subject: Re: [PATCH v4 0/6] virtio core DMA API conversion Message-ID: <20151110102733.GJ2255@suse.de> References: <20151109133624-mutt-send-email-mst@redhat.com> <1447109937.31884.42.camel@kernel.crashing.org> <1447121076.31884.61.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1447121076.31884.61.camel@kernel.crashing.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 10, 2015 at 01:04:36PM +1100, Benjamin Herrenschmidt wrote: > The "in absence of the new DT binding" doesn't make that much sense. > > Those platforms use device-trees defined since the dawn of ages by > actual open firmware implementations, they either have no iommu > representation in there (Macs, the platform code hooks it all up) or > have various properties related to the iommu but no concept of "bypass" > in there. > > We can *add* a new property under some circumstances that indicates a > bypass on a per-device basis, however that doesn't completely solve it: > >   - As I said above, what does the absence of that property mean ? An > old qemu that does bypass on all virtio or a new qemu trying to tell > you that the virtio device actually does use the iommu (or some other > environment that isn't qemu) ? You have the same problem when real PCIe devices appear that speak virtio. I think the only real (still not very nice) solution is to add a quirk to powerpc platform code that sets noop dma-ops for the existing virtio vendor/device-ids and add a DT property to opt-out of that quirk. New vendor/device-ids (as for real devices) would just not be covered by the quirk and existing emulated devices continue to work. The absence of the property just means that the quirk is in place and the system assumes no translation for virtio devices. Joerg