From: David Gibson <david@gibson.dropbear.id.au>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, "Michael S . Tsirkin" <mst@redhat.com>,
yi.l.liu@intel.com, Marcel Apfelbaum <marcel@redhat.com>,
Lan Tianyu <tianyu.lan@intel.com>,
Jason Wang <jasowang@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 04/12] memory: fix address_space_get_iotlb_entry()
Date: Fri, 12 May 2017 15:25:08 +1000 [thread overview]
Message-ID: <20170512052508.GD12908@umbus.fritz.box> (raw)
In-Reply-To: <20170511093603.GJ28293@pxdev.xzpeter.org>
[-- Attachment #1: Type: text/plain, Size: 6010 bytes --]
On Thu, May 11, 2017 at 05:36:03PM +0800, Peter Xu wrote:
> On Thu, May 11, 2017 at 11:56:38AM +1000, David Gibson wrote:
> > On Wed, May 10, 2017 at 04:01:47PM +0800, Peter Xu wrote:
> > > This function has an assumption that we will definitely call translate()
> > > once (or say, the addr will be located inside one IOMMU memory region),
> > > otherwise an empty IOTLB will be returned. Nevertheless, this is not
> > > what we want. When there is no IOMMU memory region, we should build up a
> > > static mapping for the caller, instead of an invalid IOTLB.
> > >
> > > We won't trigger this path before VT-d passthrough mode. When
> > > passthrough mode for a vhost device is setup, VT-d is possible to
> > > disable the IOMMU region for that device. Without current patch, we'll
> > > get a vhost boot failure, and it'll be failed over to virtio userspace
> > > mode.
> >
> > This doesn't look right to me. You're assuming the target is
> > address_space_memory, which might not be the case - and you should be
> > able to check from the MR you do hit. Furthermore it doesn't look
> > like you're accounting for the trivial translation if the section's
> > offset in the address space is different from its offset in the MR.
>
> Do you mean this line?
>
> addr = addr - section->offset_within_address_space
> + section->offset_within_region;
Uh.. where is that line? But.. wait, yes, I think I was mistaken. I saw:
.translated_addr = iova,
and thought that meant you were assuming an identify mapping from iova
to translated addr. But thinking more carefull, IIRC iova and
translated_addr are both relative to the MR, not the AS, so I think
that is correct after all.
> I thought it was calculating the relative address against that memory
> region. That should only be useful if we want to do further
> translate(), right? For the path that this patch tries to handle (when
> there is no translate() call), then this "addr" is useless here?
>
> Regarding to the address space assignment - do you mean, e.g., I
> should use section->address_space here instead of
> &system_address_space? If so, I can do the switch.
Yes, I think you should.
> But after all, for
> now address_space_get_iotlb_entry() is only used by vhost codes, and
> it only check against iotlb.target_as == NULL, so the address space
> didn't count too much here...
> Another reason I used &address_space_memory is that in
> vfio_iommu_map_notify() we have a check against it:
>
> if (iotlb->target_as != &address_space_memory) {
> error_report("Wrong target AS \"%s\", only system memory is allowed",
> iotlb->target_as->name ? iotlb->target_as->name : "none");
> return;
> }
>
> Or say, we have some assumptions (not only in this patch) that assumes
> this iotlb.target_as should be system_address_space.
Right, the vhost code can only handle some IOMMU setups - something
like nested IOMMUs would break it. But this way if someone sets up a
machine with an IOMMU configuration that vhost can't handle, you'll
get an error message, rather than accesses to unexpected locations,
which could cause really hard to debug corruption.
In other words we make assumptions, but we should _test_ those
assumptions.
I also think it would make sense to use address_space_translate() if we
can, since it's an existing interface for a very similar operation.
>
> Thanks,
>
> >
> > I think for the fallback path you're going to want something based on
> > address_space_translate() instead.
> >
> > > CC: Paolo Bonzini <pbonzini@redhat.com>
> > > CC: Jason Wang <jasowang@redhat.com>
> > > CC: Michael S. Tsirkin <mst@redhat.com>
> > > Signed-off-by: Peter Xu <peterx@redhat.com>
> > > ---
> > > exec.c | 20 +++++++++++++++++++-
> > > 1 file changed, 19 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/exec.c b/exec.c
> > > index 072de5d..5cfdacd 100644
> > > --- a/exec.c
> > > +++ b/exec.c
> > > @@ -463,12 +463,13 @@ address_space_translate_internal(AddressSpaceDispatch *d, hwaddr addr, hwaddr *x
> > > }
> > >
> > > /* Called from RCU critical section */
> > > -IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
> > > +IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr iova,
> > > bool is_write)
> > > {
> > > IOMMUTLBEntry iotlb = {0};
> > > MemoryRegionSection *section;
> > > MemoryRegion *mr;
> > > + hwaddr addr = iova, psize;
> > >
> > > for (;;) {
> > > AddressSpaceDispatch *d = atomic_rcu_read(&as->dispatch);
> > > @@ -478,6 +479,23 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
> > > mr = section->mr;
> > >
> > > if (!mr->iommu_ops) {
> > > + /*
> > > + * We didn't translate() but reached here. It possibly
> > > + * means it's a static mapping. If so (it should be RAM),
> > > + * we set the IOTLB up.
> > > + */
> > > + if (!iotlb.target_as && memory_region_is_ram(mr) &&
> > > + !memory_region_is_rom(mr)) {
> > > + psize = mr->ram_block->page_size;
> > > + iova &= ~(psize - 1);
> > > + iotlb = (IOMMUTLBEntry) {
> > > + .target_as = &address_space_memory,
> > > + .iova = iova,
> > > + .translated_addr = iova,
> > > + .addr_mask = psize - 1,
> > > + .perm = IOMMU_RW,
> > > + };
> > > + }
> > > break;
> > > }
> > >
> >
>
>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2017-05-12 5:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-10 8:01 [Qemu-devel] [PATCH v3 00/12] VT-d: PT (passthrough) mode support and misc fixes Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 01/12] pc: add 2.10 machine type Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 02/12] memory: tune last param of iommu_ops.translate() Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 03/12] memory: remove the last param in memory_region_iommu_replay() Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 04/12] memory: fix address_space_get_iotlb_entry() Peter Xu
2017-05-11 1:56 ` David Gibson
2017-05-11 9:36 ` Peter Xu
2017-05-12 5:25 ` David Gibson [this message]
2017-05-15 9:00 ` Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 05/12] x86-iommu: use DeviceClass properties Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 06/12] intel_iommu: renaming context entry helpers Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 07/12] intel_iommu: provide vtd_ce_get_type() Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 08/12] intel_iommu: use IOMMU_ACCESS_FLAG() Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 09/12] intel_iommu: allow dev-iotlb context entry conditionally Peter Xu
2017-05-11 2:56 ` Jason Wang
2017-05-11 3:51 ` Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 10/12] intel_iommu: support passthrough (PT) Peter Xu
2017-05-11 8:31 ` Jason Wang
2017-05-11 8:48 ` Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 11/12] intel_iommu: turn off pt before 2.9 Peter Xu
2017-05-10 8:01 ` [Qemu-devel] [PATCH v3 12/12] vhost: iommu: cache static mapping if there is Peter Xu
2017-05-11 8:35 ` Jason Wang
2017-05-11 8:59 ` Peter Xu
2017-05-12 1:54 ` Jason Wang
2017-05-10 8:55 ` [Qemu-devel] [PATCH v3 00/12] VT-d: PT (passthrough) mode support and misc fixes no-reply
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=20170512052508.GD12908@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=jasowang@redhat.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tianyu.lan@intel.com \
--cc=yi.l.liu@intel.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).