[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <acdfef1327f73f6ac67645d9f1a8e9204a0f22fb.camel@kernel.crashing.org>
Date: Mon, 04 Jun 2018 23:14:36 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Christoph Hellwig <hch@...radead.org>,
"Michael S. Tsirkin" <mst@...hat.com>
Cc: 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
Subject: Re: [RFC V2] virtio: Add platform specific DMA API translation for
virito devices
On Mon, 2018-06-04 at 05:55 -0700, Christoph Hellwig wrote:
> On Mon, Jun 04, 2018 at 03:43:09PM +0300, Michael S. Tsirkin wrote:
> > Another is that given the basic functionality is in there, optimizations
> > can possibly wait until per-device quirks in DMA API are supported.
>
> We have had per-device dma_ops for quite a while.
I've asked Ansuman to start with a patch that converts virtio to use
DMA ops always, along with an init quirk to hookup "direct" ops when
the IOMMU flag isn't set.
This will at least remove that horrid duplication of code path we have
in there.
Then we can just involve the arch in that init quirk so we can chose an
alternate set of ops when running a secure VM.
This is completely orthogonal to whether an iommu exist qemu side or
not, and should be entirely solved on the Linux side.
Cheers,
Ben.
Powered by blists - more mailing lists