From: Peter Xu <peterx@redhat.com>
To: Wei Huang <wei.huang2@amd.com>
Cc: ehabkost@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,
alex.williamson@redhat.com, pbonzini@redhat.com,
Suravee.Suthikulpanit@amd.com, rth@twiddle.net
Subject: Re: [PATCH V2 2/3] amd-iommu: Sync IOVA-to-GPA translation during page invalidation
Date: Fri, 2 Oct 2020 15:11:30 -0400 [thread overview]
Message-ID: <20201002191130.GF5473@xz-x1> (raw)
In-Reply-To: <20201002145907.1294353-3-wei.huang2@amd.com>
On Fri, Oct 02, 2020 at 09:59:06AM -0500, Wei Huang wrote:
> +static void amdvi_sync_domain(AMDVIState *s, uint32_t domid,
> + uint64_t addr, uint16_t flags)
> +{
[...]
> + /*
> + * In case of syncing more than a page, we invalidate the entire
> + * address range and re-walk the whole page table.
> + */
> + if (size == AMDVI_PGSZ_ENTIRE) {
> + IOMMU_NOTIFIER_FOREACH(n, &as->iommu) {
> + amdvi_address_space_unmap(as, n);
> + }
> + } else if (size > 0x1000) {
> + IOMMU_NOTIFIER_FOREACH(n, &as->iommu) {
> + if (n->start <= addr && addr + size < n->end) {
> + amdvi_address_space_unmap(as, n);
> + }
> + }
> + }
So this may not work... Because DMA could happen concurrently with the page
sync, so the DMA could fail if the mapping is suddenly gone (even if it's a
very short period).
We encountered this problem on x86 and those will be reported as host DMAR
errors (since those pages were missing), please feel free to have a look at:
63b88968f1 ("intel-iommu: rework the page walk logic", 2018-05-23)
Majorly this paragraph:
For each VTDAddressSpace, now we maintain what IOVA ranges we have
mapped and what we have not. With that information, now we only send
MAP or UNMAP when necessary. Say, we don't send MAP notifies if we
know we have already mapped the range, meanwhile we don't send UNMAP
notifies if we know we never mapped the range at all.
So the simple idea is, as long as one page was mapped and it's not unmapped, we
can _never_ unmap it.. because the device might be using it simultaneously.
What VT-d does right now is to maintain a per-device iova tree, so that we know
what exactly have been mapped. That's kind of an overkill for sure (especially
because vfio kernel module will maintain a similar iova tree, so it's at least
kind of duplicated), however that should fix this problem.
--
Peter Xu
next prev parent reply other threads:[~2020-10-02 19:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 14:59 [PATCH V2 0/3] Passthru device support under emulated amd-iommu Wei Huang
2020-10-02 14:59 ` [PATCH V2 1/3] amd-iommu: Add address space notifier and replay support Wei Huang
2020-10-02 18:53 ` Peter Xu
2020-10-02 14:59 ` [PATCH V2 2/3] amd-iommu: Sync IOVA-to-GPA translation during page invalidation Wei Huang
2020-10-02 19:11 ` Peter Xu [this message]
2020-10-02 14:59 ` [PATCH V2 3/3] amd-iommu: Fix amdvi_mmio_trace() to differentiate MMIO R/W Wei Huang
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=20201002191130.GF5473@xz-x1 \
--to=peterx@redhat.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=alex.williamson@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=wei.huang2@amd.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).