virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: virtualization@lists.linux-foundation.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: virtio DMA API?
Date: Mon, 25 Aug 2014 12:20:53 -0700	[thread overview]
Message-ID: <CALCETrXz2nc0VKyGT8h_CdaNUusuaxVEWPxzNrLSQ_Ubz3DO0g@mail.gmail.com> (raw)
In-Reply-To: <20140825185441.GB14061@laptop.dumpdata.com>

On Mon, Aug 25, 2014 at 11:54 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Mon, Aug 25, 2014 at 10:18:46AM -0700, Andy Lutomirski wrote:
>> Currently, a lot of the virtio code assumes that bus (i.e. hypervisor)
>> addresses are the same as physical address.  This is false on Xen, so
>> virtio is completely broken.  I wouldn't be surprised if it also
>> becomes a problem the first time that someone sticks a physical
>> "virtio" device on a 32-bit bus on an ARM SOC with more than 4G RAM.
>>
>> Would you accept patches to convert virtio_ring and virtio_pci to use
>> the DMA APIs?  I think that the only real catch will be that
>> virtio_ring's approach to freeing indirect blocks is currently
>> incompatible with the DMA API -- it assumes that knowing the bus
>> address is enough to call kfree, and I don't think that the DMA API
>> provides a reverse mapping like that.
>
> If you use the dma_map/unmap_sg all of that ends up being stuck in the
> sg structure (sg->dma_address ends with the DMA addr, sg_phys(sg) gives
> you the physical address).

Unfortunately, virtio_ring doesn't hang on to the sg structure until
complation.  I don't think it can, either -- if I read it right, the
virtio_net driver uses one scatterlist per queue instead of one
scatterlist per pending skb, so the sg entries could be overwritten by
the time virtio_ring should unmap it.  Fortunately, I think that
dma_unmap_single can handle this case just fine.

I have a WIP here:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=virtio_ring_xen

It works, but it's mostly missing unmap calls.  If there's no iommu or
swiotlb, then there's nothing to leak, so it's okay.  If you do, then
this driver will eventually explode.  I'll send patches once I have it
fixed up.

--Andy

  reply	other threads:[~2014-08-25 19:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-25 17:18 virtio DMA API? Andy Lutomirski
2014-08-25 18:54 ` Konrad Rzeszutek Wilk
2014-08-25 19:20   ` Andy Lutomirski [this message]
2014-08-27 11:10 ` Rusty Russell
2014-08-27 11:52   ` Michael S. Tsirkin
2014-08-27 19:49     ` Konrad Rzeszutek Wilk
2014-08-27 21:32     ` Benjamin Herrenschmidt
2014-08-27 14:55   ` Andy Lutomirski
2014-08-27 21:31   ` Benjamin Herrenschmidt
2014-08-29 15:06     ` Konrad Rzeszutek Wilk

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=CALCETrXz2nc0VKyGT8h_CdaNUusuaxVEWPxzNrLSQ_Ubz3DO0g@mail.gmail.com \
    --to=luto@amacapital.net \
    --cc=konrad.wilk@oracle.com \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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).