From: "Michael S. Tsirkin" <mst@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Will Deacon <will.deacon@arm.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
aik@ozlabs.ru, robh@kernel.org, joe@perches.com,
elfring@users.sourceforge.net, david@gibson.dropbear.id.au,
jasowang@redhat.com, mpe@ellerman.id.au, linuxram@us.ibm.com,
haren@linux.vnet.ibm.com, paulus@samba.org,
srikar@linux.vnet.ibm.com, robin.murphy@arm.com,
jean-philippe.brucker@arm.com, marc.zyngier@arm.com
Subject: Re: [RFC 0/4] Virtio uses DMA API for all devices
Date: Tue, 7 Aug 2018 02:45:25 +0300 [thread overview]
Message-ID: <20180807024503-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <93518075238a07e9f011774d89bdc652c083f1ba.camel@kernel.crashing.org>
On Tue, Aug 07, 2018 at 08:13:56AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2018-08-07 at 00:46 +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 07, 2018 at 07:26:35AM +1000, Benjamin Herrenschmidt wrote:
> > > On Mon, 2018-08-06 at 23:35 +0300, Michael S. Tsirkin wrote:
> > > > > As I said replying to Christoph, we are "leaking" into the interface
> > > > > something here that is really what's the VM is doing to itself, which
> > > > > is to stash its memory away in an inaccessible place.
> > > > >
> > > > > Cheers,
> > > > > Ben.
> > > >
> > > > I think Christoph merely objects to the specific implementation. If
> > > > instead you do something like tweak dev->bus_dma_mask for the virtio
> > > > device I think he won't object.
> > >
> > > Well, we don't have "bus_dma_mask" yet ..or you mean dma_mask ?
> > >
> > > So, something like that would be a possibility, but the problem is that
> > > the current virtio (guest side) implementation doesn't honor this when
> > > not using dma ops and will not use dma ops if not using iommu, so back
> > > to square one.
> >
> > Well we have the RFC for that - the switch to using DMA ops unconditionally isn't
> > problematic itself IMHO, for now that RFC is blocked
> > by its perfromance overhead for now but Christoph says
> > he's trying to remove that for direct mappings,
> > so we should hopefully be able to get there in X weeks.
>
> That would be good yes.
>
> ../..
>
> > > --- a/drivers/virtio/virtio_ring.c
> > > +++ b/drivers/virtio/virtio_ring.c
> > > @@ -155,7 +155,7 @@ static bool vring_use_dma_api(struct virtio_device
> > > *vdev)
> > > * the DMA API if we're a Xen guest, which at least allows
> > > * all of the sensible Xen configurations to work correctly.
> > > */
> > > - if (xen_domain())
> > > + if (xen_domain() || arch_virtio_direct_dma_ops(&vdev->dev))
> > > return true;
> > >
> > > return false;
> >
> > Right but can't we fix the retpoline overhead such that
> > vring_use_dma_api will not be called on data path any longer, making
> > this a setup time check?
>
> Yes it needs to be a setup time check regardless actually !
>
> The above is broken, sorry I was a bit quick here (too early in the
> morning... ugh). We don't want the arch to go override the dma ops
> every time that is callled.
>
> But yes, if we can fix the overhead, it becomes just a matter of
> setting up the "right" ops automatically.
>
> > > (Passing the dev allows the arch to know this is a virtio device in
> > > "direct" mode or whatever we want to call the !iommu case, and
> > > construct appropriate DMA ops for it, which aren't the same as the DMA
> > > ops of any other PCI device who *do* use the iommu).
> >
> > I think that's where Christoph might have specific ideas about it.
>
> OK well, assuming Christoph can solve the direct case in a way that
> also work for the virtio !iommu case, we still want some bit of logic
> somewhere that will "switch" to swiotlb based ops if the DMA mask is
> limited.
>
> You mentioned an RFC for that ? Do you happen to have a link ?
No but Christoph did I think.
> It would be indeed ideal if all we had to do was setup some kind of
> bus_dma_mask on all PCI devices and have virtio automagically insert
> swiotlb when necessary.
>
> Cheers,
> Ben.
>
next prev parent reply other threads:[~2018-08-06 23:45 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-20 3:59 [RFC 0/4] Virtio uses DMA API for all devices Anshuman Khandual
2018-07-20 3:59 ` [RFC 1/4] virtio: Define virtio_direct_dma_ops structure Anshuman Khandual
2018-07-30 9:24 ` Christoph Hellwig
2018-07-31 4:01 ` Anshuman Khandual
2018-07-20 3:59 ` [RFC 2/4] virtio: Override device's DMA OPS with virtio_direct_dma_ops selectively Anshuman Khandual
2018-07-28 8:56 ` Anshuman Khandual
2018-07-28 21:16 ` Michael S. Tsirkin
2018-07-30 4:15 ` Anshuman Khandual
2018-07-30 9:30 ` Christoph Hellwig
2018-07-31 6:39 ` Anshuman Khandual
2018-07-30 9:25 ` Christoph Hellwig
2018-07-31 7:00 ` Anshuman Khandual
2018-07-20 3:59 ` [RFC 3/4] virtio: Force virtio core to use DMA API callbacks for all virtio devices Anshuman Khandual
2018-07-20 3:59 ` [RFC 4/4] virtio: Add platform specific DMA API translation for virito devices Anshuman Khandual
2018-07-20 13:15 ` Michael S. Tsirkin
2018-07-23 2:16 ` Anshuman Khandual
2018-07-25 4:30 ` Anshuman Khandual
2018-07-25 13:31 ` Michael S. Tsirkin
2018-07-20 13:16 ` [RFC 0/4] Virtio uses DMA API for all devices Michael S. Tsirkin
2018-07-23 6:28 ` Anshuman Khandual
2018-07-23 9:08 ` Michael S. Tsirkin
2018-07-25 3:26 ` Anshuman Khandual
2018-07-27 11:31 ` Michael S. Tsirkin
2018-07-28 8:37 ` Anshuman Khandual
2018-07-27 9:58 ` Will Deacon
2018-07-27 10:58 ` Anshuman Khandual
2018-07-30 9:34 ` Christoph Hellwig
2018-07-30 10:28 ` Michael S. Tsirkin
2018-07-30 11:18 ` Christoph Hellwig
2018-07-30 13:26 ` Michael S. Tsirkin
2018-07-31 17:30 ` Christoph Hellwig
2018-07-31 20:36 ` Benjamin Herrenschmidt
2018-08-01 8:16 ` Will Deacon
2018-08-01 8:36 ` Christoph Hellwig
2018-08-01 9:05 ` Will Deacon
2018-08-01 22:41 ` Michael S. Tsirkin
2018-08-01 22:35 ` Michael S. Tsirkin
2018-08-02 15:24 ` Benjamin Herrenschmidt
2018-08-02 15:41 ` Michael S. Tsirkin
2018-08-02 16:01 ` Benjamin Herrenschmidt
2018-08-02 17:19 ` Michael S. Tsirkin
2018-08-02 17:53 ` Benjamin Herrenschmidt
2018-08-02 20:52 ` Michael S. Tsirkin
2018-08-02 21:13 ` Benjamin Herrenschmidt
2018-08-02 21:51 ` Michael S. Tsirkin
2018-08-03 7:05 ` Christoph Hellwig
2018-08-03 15:58 ` Benjamin Herrenschmidt
2018-08-03 16:02 ` Christoph Hellwig
2018-08-03 18:58 ` Benjamin Herrenschmidt
2018-08-04 8:21 ` Christoph Hellwig
2018-08-05 1:10 ` Benjamin Herrenschmidt
2018-08-05 7:29 ` Christoph Hellwig
2018-08-05 21:16 ` Benjamin Herrenschmidt
2018-08-05 21:30 ` Benjamin Herrenschmidt
2018-08-06 9:42 ` Christoph Hellwig
2018-08-06 19:52 ` Benjamin Herrenschmidt
2018-08-07 6:21 ` Christoph Hellwig
2018-08-07 6:42 ` Benjamin Herrenschmidt
2018-08-07 13:55 ` Christoph Hellwig
2018-08-07 20:32 ` Benjamin Herrenschmidt
2018-08-08 6:31 ` Christoph Hellwig
2018-08-08 10:07 ` Benjamin Herrenschmidt
2018-08-08 12:30 ` Christoph Hellwig
2018-08-08 13:18 ` Benjamin Herrenschmidt
2018-08-08 20:31 ` Michael S. Tsirkin
2018-08-08 22:13 ` Benjamin Herrenschmidt
2018-08-09 2:00 ` Benjamin Herrenschmidt
2018-08-09 5:40 ` Christoph Hellwig
2018-09-07 0:09 ` Jiandi An
2018-09-10 6:19 ` Christoph Hellwig
2018-09-10 8:53 ` Gerd Hoffmann
2018-08-03 19:07 ` Michael S. Tsirkin
2018-08-04 1:11 ` Benjamin Herrenschmidt
2018-08-04 1:16 ` Benjamin Herrenschmidt
2018-08-05 0:22 ` Michael S. Tsirkin
2018-08-05 4:52 ` Benjamin Herrenschmidt
2018-08-06 13:46 ` Michael S. Tsirkin
2018-08-06 19:56 ` Benjamin Herrenschmidt
2018-08-06 20:35 ` Michael S. Tsirkin
2018-08-06 21:26 ` Benjamin Herrenschmidt
2018-08-06 21:46 ` Michael S. Tsirkin
2018-08-06 22:13 ` Benjamin Herrenschmidt
2018-08-06 23:16 ` Benjamin Herrenschmidt
2018-08-06 23:45 ` Michael S. Tsirkin [this message]
2018-08-07 0:18 ` Benjamin Herrenschmidt
2018-08-07 6:32 ` Christoph Hellwig
2018-08-07 6:27 ` Christoph Hellwig
2018-08-07 6:44 ` Benjamin Herrenschmidt
2018-08-07 6:18 ` Christoph Hellwig
2018-08-07 6:16 ` Christoph Hellwig
2018-08-06 23:18 ` Benjamin Herrenschmidt
2018-08-07 6:12 ` Christoph Hellwig
2018-08-04 1:18 ` Benjamin Herrenschmidt
2018-08-04 1:22 ` Benjamin Herrenschmidt
2018-08-05 0:23 ` Michael S. Tsirkin
2018-08-03 19:17 ` Michael S. Tsirkin
2018-08-04 8:15 ` Christoph Hellwig
2018-08-05 0:09 ` Michael S. Tsirkin
2018-08-05 1:11 ` Benjamin Herrenschmidt
2018-08-05 7:25 ` Christoph Hellwig
2018-08-05 0:53 ` Benjamin Herrenschmidt
2018-08-05 0:27 ` Michael S. Tsirkin
2018-08-06 14:05 ` Will Deacon
2018-08-01 21:56 ` Michael S. Tsirkin
2018-08-02 15:33 ` Benjamin Herrenschmidt
2018-08-02 20:53 ` Michael S. Tsirkin
2018-08-03 7:06 ` Christoph Hellwig
2018-08-02 20:55 ` Michael S. Tsirkin
2018-08-03 2:41 ` Jason Wang
2018-08-03 19:08 ` Michael S. Tsirkin
2018-08-04 1:21 ` Benjamin Herrenschmidt
2018-08-05 0:24 ` Michael S. Tsirkin
2018-08-06 9:02 ` Anshuman Khandual
2018-08-06 13:36 ` Michael S. Tsirkin
2018-08-06 15:24 ` Christoph Hellwig
2018-08-06 16:06 ` Michael S. Tsirkin
2018-08-06 16:10 ` Christoph Hellwig
2018-08-06 16:13 ` Michael S. Tsirkin
2018-08-06 16:34 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180807024503-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=aik@ozlabs.ru \
--cc=benh@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=elfring@users.sourceforge.net \
--cc=haren@linux.vnet.ibm.com \
--cc=hch@infradead.org \
--cc=jasowang@redhat.com \
--cc=jean-philippe.brucker@arm.com \
--cc=joe@perches.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=linuxram@us.ibm.com \
--cc=marc.zyngier@arm.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).