[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180803221634-mutt-send-email-mst@kernel.org>
Date: Fri, 3 Aug 2018 22:17:32 +0300
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Will Deacon <will.deacon@....com>,
Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
virtualization@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
aik@...abs.ru, robh@...nel.org, joe@...ches.com,
elfring@...rs.sourceforge.net, david@...son.dropbear.id.au,
jasowang@...hat.com, mpe@...erman.id.au, linuxram@...ibm.com,
haren@...ux.vnet.ibm.com, paulus@...ba.org,
srikar@...ux.vnet.ibm.com, robin.murphy@....com,
jean-philippe.brucker@....com, marc.zyngier@....com
Subject: Re: [RFC 0/4] Virtio uses DMA API for all devices
On Fri, Aug 03, 2018 at 12:05:07AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 02, 2018 at 04:13:09PM -0500, Benjamin Herrenschmidt wrote:
> > So let's differenciate the two problems of having an IOMMU (real or
> > emulated) which indeeds adds overhead etc... and using the DMA API.
> >
> > At the moment, virtio does this all over the place:
> >
> > if (use_dma_api)
> > dma_map/alloc_something(...)
> > else
> > use_pa
> >
> > The idea of the patch set is to do two, somewhat orthogonal, changes
> > that together achieve what we want. Let me know where you think there
> > is "a bunch of issues" because I'm missing it:
> >
> > 1- Replace the above if/else constructs with just calling the DMA API,
> > and have virtio, at initialization, hookup its own dma_ops that just
> > "return pa" (roughly) when the IOMMU stuff isn't used.
> >
> > This adds an indirect function call to the path that previously didn't
> > have one (the else case above). Is that a significant/measurable
> > overhead ?
>
> If you call it often enough it does:
>
> https://www.spinics.net/lists/netdev/msg495413.html
>
> > 2- Make virtio use the DMA API with our custom platform-provided
> > swiotlb callbacks when needed, that is when not using IOMMU *and*
> > running on a secure VM in our case.
>
> And total NAK the customer platform-provided part of this. We need
> a flag passed in from the hypervisor that the device needs all bus
> specific dma api treatment, and then just use the normal plaform
> dma mapping setup. To get swiotlb you'll need to then use the DT/ACPI
> dma-range property to limit the addressable range, and a swiotlb
> capable plaform will use swiotlb automatically.
It seems reasonable to teach a platform to override dma-range
for a specific device e.g. in case it knows about bugs in ACPI.
--
MST
Powered by blists - more mailing lists