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 Content-Length: 1635 Lines: 36 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/