From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Cc: mark.rutland@arm.com, virtio-dev@lists.oasis-open.org,
lorenzo.pieralisi@arm.com, tnowicki@caviumnetworks.com,
devicetree@vger.kernel.org, marc.zyngier@arm.com,
linux-pci@vger.kernel.org, joro@8bytes.org, will.deacon@arm.com,
virtualization@lists.linux-foundation.org, eric.auger@redhat.com,
iommu@lists.linux-foundation.org, robh+dt@kernel.org,
bhelgaas@google.com, robin.murphy@arm.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v5 5/7] iommu: Add virtio-iommu driver
Date: Tue, 27 Nov 2018 13:53:17 -0500 [thread overview]
Message-ID: <20181127131455-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ef97313f-4795-9537-e0b8-8bf6751db6a6@arm.com>
On Tue, Nov 27, 2018 at 06:10:46PM +0000, Jean-Philippe Brucker wrote:
> On 27/11/2018 18:04, Michael S. Tsirkin wrote:
> > On Tue, Nov 27, 2018 at 05:50:50PM +0000, Jean-Philippe Brucker wrote:
> >> On 23/11/2018 22:02, Michael S. Tsirkin wrote:
> >>>> +/*
> >>>> + * __viommu_sync_req - Complete all in-flight requests
> >>>> + *
> >>>> + * Wait for all added requests to complete. When this function returns, all
> >>>> + * requests that were in-flight at the time of the call have completed.
> >>>> + */
> >>>> +static int __viommu_sync_req(struct viommu_dev *viommu)
> >>>> +{
> >>>> + int ret = 0;
> >>>> + unsigned int len;
> >>>> + size_t write_len;
> >>>> + struct viommu_request *req;
> >>>> + struct virtqueue *vq = viommu->vqs[VIOMMU_REQUEST_VQ];
> >>>> +
> >>>> + assert_spin_locked(&viommu->request_lock);
> >>>> +
> >>>> + virtqueue_kick(vq);
> >>>> +
> >>>> + while (!list_empty(&viommu->requests)) {
> >>>> + len = 0;
> >>>> + req = virtqueue_get_buf(vq, &len);
> >>>> + if (!req)
> >>>> + continue;
> >>>> +
> >>>> + if (!len)
> >>>> + viommu_set_req_status(req->buf, req->len,
> >>>> + VIRTIO_IOMMU_S_IOERR);
> >>>> +
> >>>> + write_len = req->len - req->write_offset;
> >>>> + if (req->writeback && len == write_len)
> >>>> + memcpy(req->writeback, req->buf + req->write_offset,
> >>>> + write_len);
> >>>> +
> >>>> + list_del(&req->list);
> >>>> + kfree(req);
> >>>> + }
> >>>
> >>> I didn't notice this in the past but it seems this will spin
> >>> with interrupts disabled until host handles the request.
> >>> Please do not do this - host execution can be another
> >>> task that needs the same host CPU. This will then disable
> >>> interrupts for a very very long time.
> >>
> >> In the guest yes, but that doesn't prevent the host from running another
> >> task right?
> >
> > Doesn't prevent it but it will delay it significantly
> > until scheduler decides to kick the VCPU task out.
> >
> >> My tests run fine when QEMU is bound to a single CPU, even
> >> though vcpu and viommu run in different threads
> >>
> >>> What to do then? Queue in software and wake up task.
> >>
> >> Unfortunately I can't do anything here, because IOMMU drivers can't
> >> sleep in the iommu_map() or iommu_unmap() path.
> >>
> >> The problem is the same
> >> for all IOMMU drivers. That's because the DMA API allows drivers to call
> >> some functions with interrupts disabled. For example
> >> Documentation/DMA-API-HOWTO.txt allows dma_alloc_coherent() and
> >> dma_unmap_single() to be called in interrupt context.
> >
> > In fact I don't really understand how it's supposed to
> > work at all: you only sync when ring is full.
> > So host may not have seen your map request if ring
> > is not full.
> > Why is it safe to use the address with a device then?
>
> viommu_map() calls viommu_send_req_sync(), which does the sync
> immediately after adding the MAP request.
>
> Thanks,
> Jean
I see. So it happens on every request. Maybe you should clear
event index then. This way if exits are disabled you know that
host is processing the ring. Event index is good for when
you don't care when it will be processed, you just want
to reduce number of exits as much as possible.
--
MST
next prev parent reply other threads:[~2018-11-27 18:53 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-22 19:37 [PATCH v5 0/7] Add virtio-iommu driver Jean-Philippe Brucker
2018-11-22 19:37 ` [PATCH v5 1/7] dt-bindings: virtio-mmio: Add IOMMU description Jean-Philippe Brucker
2018-11-22 19:37 ` [PATCH v5 2/7] dt-bindings: virtio: Add virtio-pci-iommu node Jean-Philippe Brucker
2018-11-22 19:37 ` [PATCH v5 3/7] of: Allow the iommu-map property to omit untranslated devices Jean-Philippe Brucker
2018-11-22 19:37 ` [PATCH v5 4/7] PCI: OF: Initialize dev->fwnode appropriately Jean-Philippe Brucker
2018-11-22 19:37 ` [PATCH v5 5/7] iommu: Add virtio-iommu driver Jean-Philippe Brucker
[not found] ` <20181122193801.50510-6-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2018-11-23 8:27 ` Auger Eric
2018-11-23 21:48 ` Michael S. Tsirkin
2018-11-27 17:58 ` Jean-Philippe Brucker
2018-11-27 18:10 ` Michael S. Tsirkin
2018-11-23 21:56 ` Michael S. Tsirkin
2018-11-27 17:55 ` Jean-Philippe Brucker
2018-11-27 18:10 ` Michael S. Tsirkin
2018-12-07 18:52 ` Jean-Philippe Brucker
[not found] ` <e1dde79c-0bc4-ea99-1bb0-9e70b56955fb-5wv7dgnIgG8@public.gmane.org>
2018-12-12 14:56 ` [virtio-dev] " Michael S. Tsirkin
[not found] ` <20181212093709-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-12-12 15:27 ` Auger Eric
2018-12-13 12:37 ` Robin Murphy
2018-12-13 14:13 ` Auger Eric
2018-11-23 22:02 ` Michael S. Tsirkin
2018-11-27 17:50 ` Jean-Philippe Brucker
2018-11-27 18:04 ` Michael S. Tsirkin
2018-11-27 18:10 ` Jean-Philippe Brucker
2018-11-27 18:53 ` Michael S. Tsirkin [this message]
2018-12-10 15:06 ` Jean-Philippe Brucker
2018-12-10 22:53 ` Michael S. Tsirkin
[not found] ` <20181210175132-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2018-12-11 16:29 ` Jean-Philippe Brucker
2018-11-27 18:13 ` Michael S. Tsirkin
2018-11-22 19:38 ` [PATCH v5 6/7] iommu/virtio: Add probe request Jean-Philippe Brucker
2018-11-22 19:38 ` [PATCH v5 7/7] iommu/virtio: Add event queue Jean-Philippe Brucker
2018-11-23 8:28 ` [PATCH v5 0/7] Add virtio-iommu driver Auger Eric
2018-11-27 7:09 ` Bharat Bhushan
[not found] ` <20181122193801.50510-1-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2018-11-27 16:53 ` Michael S. Tsirkin
2018-11-27 17:09 ` Auger Eric
[not found] ` <6c061729-c404-ac25-f86f-7fe222bf5bc7-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-11-27 17:16 ` Michael S. Tsirkin
2018-11-27 18:02 ` Auger Eric
2018-12-03 13:27 ` Auger Eric
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=20181127131455-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe.brucker@arm.com \
--cc=joro@8bytes.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=tnowicki@caviumnetworks.com \
--cc=virtio-dev@lists.oasis-open.org \
--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).