From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Linux Virtualization <virtualization@lists.linux-foundation.org>,
"linux390@de.ibm.com" <linux390@de.ibm.com>
Subject: Re: [PATCH 3/3] virtio_pci: Use the DMA API for virtqueues
Date: Wed, 27 Aug 2014 14:52:48 -0400 [thread overview]
Message-ID: <20140827185248.GA6568@laptop.dumpdata.com> (raw)
In-Reply-To: <CALCETrV8sbqvbQk7+JRyE4FxQ=o+RoEMh4hgA3-yNUegGgF08Q@mail.gmail.com>
On Wed, Aug 27, 2014 at 10:35:10AM -0700, Andy Lutomirski wrote:
> On Wed, Aug 27, 2014 at 10:32 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, Aug 26, 2014 at 02:17:02PM -0700, Andy Lutomirski wrote:
> >> A virtqueue is a coherent DMA mapping. Use the DMA API for it.
> >> This fixes virtio_pci on Xen.
> >>
> >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> >> ---
> >> drivers/virtio/virtio_pci.c | 25 ++++++++++++++++++-------
> >> 1 file changed, 18 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
> >> index 3d1463c6b120..19039c5bec24 100644
> >> --- a/drivers/virtio/virtio_pci.c
> >> +++ b/drivers/virtio/virtio_pci.c
> >> @@ -80,8 +80,9 @@ struct virtio_pci_vq_info
> >> /* the number of entries in the queue */
> >> int num;
> >>
> >> - /* the virtual address of the ring queue */
> >> - void *queue;
> >> + /* the ring queue */
> >> + void *queue; /* virtual address */
> >> + dma_addr_t queue_dma_addr; /* bus address */
> >>
> >> /* the list node for the virtqueues list */
> >> struct list_head node;
> >> @@ -417,15 +418,16 @@ static struct virtqueue *setup_vq(struct virtio_device *vdev, unsigned index,
> >> info->num = num;
> >> info->msix_vector = msix_vec;
> >>
> >> - size = PAGE_ALIGN(vring_size(num, VIRTIO_PCI_VRING_ALIGN));
> >> - info->queue = alloc_pages_exact(size, GFP_KERNEL|__GFP_ZERO);
> >> + size = vring_size(num, VIRTIO_PCI_VRING_ALIGN);
> >> + info->queue = dma_zalloc_coherent(vdev->dev.parent, size,
> >> + &info->queue_dma_addr, GFP_KERNEL);
> >> if (info->queue == NULL) {
> >> err = -ENOMEM;
> >> goto out_info;
> >> }
> >>
> >> /* activate the queue */
> >> - iowrite32(virt_to_phys(info->queue) >> VIRTIO_PCI_QUEUE_ADDR_SHIFT,
> >> + iowrite32(info->queue_dma_addr >> VIRTIO_PCI_QUEUE_ADDR_SHIFT,
> >> vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
> >>
> >> /* create the vring */
> >> @@ -462,7 +464,8 @@ out_assign:
> >> vring_del_virtqueue(vq);
> >> out_activate_queue:
> >> iowrite32(0, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
> >> - free_pages_exact(info->queue, size);
> >> + dma_free_coherent(vdev->dev.parent, size,
> >> + info->queue, info->queue_dma_addr);
> >> out_info:
> >> kfree(info);
> >> return ERR_PTR(err);
> >> @@ -493,7 +496,8 @@ static void vp_del_vq(struct virtqueue *vq)
> >> iowrite32(0, vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
> >>
> >> size = PAGE_ALIGN(vring_size(info->num, VIRTIO_PCI_VRING_ALIGN));
> >> - free_pages_exact(info->queue, size);
> >> + dma_free_coherent(vq->vdev->dev.parent, size,
> >> + info->queue, info->queue_dma_addr);
> >> kfree(info);
> >> }
> >>
> >> @@ -712,6 +716,13 @@ static int virtio_pci_probe(struct pci_dev *pci_dev,
> >> if (err)
> >> goto out;
> >>
> >> + /*
> >> + * We support 64-bit DMA. If this fails (e.g. some bridge
> >> + * or PV code doesn't or DAC is disabled), then we're okay
> >> + * with 32-bit DMA.
> >
> > <scratches his head>
> >
> > I am having a hard time parsing that. Could you expand a bit the
> > faulting use-case please?
> >
> >> + */
> >> + dma_set_mask_and_coherent(&pci_dev->dev, DMA_BIT_MASK(64));
> >
> > The usual process is:
> >
> > ret = dma_set_mask_and_coherent(..)
> > if (ret)
> > ret = dma_set_mask_and_coherent(.., DMA_BIT_MASK(32))
> >
> > if (ret)
> > pr_warn("We are truly screwed. Good luck!\n");
> >
>
> I assumed that, if dma_set_mask_and_coherent(..., DMA_BIT_BASK(64))
> fails, then we can still do DMA, just not 64-bit DMA. This driver
> should be fine with that -- it'll just be a bit slower.
Right. It should fail back to 32-bit (the default on PCI bus).
I was merely thinking of the error reporting might be useful
but on second thought - saying that the user is screwed - is
a bad idea.
>
> If that's not a safe assumption, I can change it.
>
> --Andy
next prev parent reply other threads:[~2014-08-27 18:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 21:16 [PATCH 0/3] virtio: Clean up scatterlists and use the DMA API Andy Lutomirski
2014-08-26 21:17 ` [PATCH 1/3] virtio_ring: Remove sg_next indirection Andy Lutomirski
2014-09-01 0:58 ` Rusty Russell
2014-09-01 1:42 ` Andy Lutomirski
2014-09-01 6:59 ` Michael S. Tsirkin
2014-09-01 17:15 ` Andy Lutomirski
2014-08-26 21:17 ` [PATCH 2/3] virtio_ring: Use DMA APIs Andy Lutomirski
2014-08-27 7:29 ` Christian Borntraeger
2014-08-27 17:35 ` Konrad Rzeszutek Wilk
2014-08-27 17:39 ` Andy Lutomirski
2014-08-26 21:17 ` [PATCH 3/3] virtio_pci: Use the DMA API for virtqueues Andy Lutomirski
2014-08-27 17:32 ` Konrad Rzeszutek Wilk
2014-08-27 17:35 ` Andy Lutomirski
2014-08-27 18:52 ` Konrad Rzeszutek Wilk [this message]
2014-08-27 6:46 ` [PATCH 0/3] virtio: Clean up scatterlists and use the DMA API Stefan Hajnoczi
2014-08-27 15:11 ` Andy Lutomirski
2014-08-27 15:45 ` Michael S. Tsirkin
2014-08-27 15:50 ` Andy Lutomirski
2014-08-27 16:13 ` Christopher Covington
2014-08-27 16:19 ` Andy Lutomirski
2014-08-27 17:34 ` Christopher Covington
2014-08-27 17:37 ` Andy Lutomirski
2014-08-27 17:50 ` Christopher Covington
2014-08-27 20:52 ` Christian Borntraeger
2014-08-27 17:27 ` Konrad Rzeszutek Wilk
2014-08-27 18:10 ` Stefan Hajnoczi
2014-08-27 18:58 ` Konrad Rzeszutek Wilk
2014-08-27 7:54 ` Cornelia Huck
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=20140827185248.GA6568@laptop.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=linux-s390@vger.kernel.org \
--cc=linux390@de.ibm.com \
--cc=luto@amacapital.net \
--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).