All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Yan Zhao <yan.y.zhao@intel.com>, pbonzini@redhat.com
Cc: qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] memory: do not do out of bound notification
Date: Wed, 19 Jun 2019 15:17:41 +0200	[thread overview]
Message-ID: <39c4c32b-e34a-8d8f-abbc-ab346ec5bed7@redhat.com> (raw)
In-Reply-To: <1560934185-14152-1-git-send-email-yan.y.zhao@intel.com>

Hi Yan,

[+ Peter]

On 6/19/19 10:49 AM, Yan Zhao wrote:
> even if an entry overlaps with notifier's range, should not map/unmap
> out of bound part in the entry.

I don't think the patch was based on the master as the trace at the very
end if not part of the upstream code.
> 
> This would cause problem in below case:
> 1. initially there are two notifiers with ranges
> 0-0xfedfffff, 0xfef00000-0xffffffffffffffff,
> IOVAs from 0x3c000000 - 0x3c1fffff is in shadow page table.
> 
> 2. in vfio, memory_region_register_iommu_notifier() is followed by
> memory_region_iommu_replay(), which will first call address space unmap,
> and walk and add back all entries in vtd shadow page table. e.g.
> (1) for notifier 0-0xfedfffff,
>     IOVAs from 0 - 0xffffffff get unmapped,
>     and IOVAs from 0x3c000000 - 0x3c1fffff get mapped

While the patch looks sensible, the issue is the notifier scope used in
vtd_address_space_unmap is not a valid mask (ctpop64(size) != 1). Then
the size is recomputed (either using n = 64 - clz64(size) for the 1st
notifier or n = s->aw_bits for the 2d) and also the entry (especially
for the 2d notifier where it becomes 0) to get a proper alignment.

vtd_page_walk sends notifications per block or page (with valid
addr_mask) so stays within the notifier.

Modifying the entry->iova/addr_mask again in memory_region_notify_one
leads to unaligned start address / addr_mask. I don't think we want that.

Can't we modity the vtd_address_space_unmap() implementation to split
the invalidation in smaller chunks instead?


Thanks

Eric


> (2) for notifier 0xfef00000-0xffffffffffffffff
>     IOVAs from 0 - 0x7fffffffff get unmapped,>     but IOVAs from 0x3c000000 - 0x3c1fffff cannot get mapped back.
> 
> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
> ---
>  memory.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/memory.c b/memory.c
> index 07c8315..a6b9da6 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -1948,6 +1948,14 @@ void memory_region_notify_one(IOMMUNotifier *notifier,
>          return;
>      }
>  
> +    if (entry->iova < notifier->start) {
> +        entry->iova = notifier->start;
> +    }
> +
> +    if (entry->iova + entry->addr_mask > notifier->end) {
> +        entry->addr_mask = notifier->end - entry->iova;> +    }
> +
>      if (entry->perm & IOMMU_RW) {
>          printf("map %lx %lx\n", entry->iova, entry->iova + entry->addr_mask);
>          request_flags = IOMMU_NOTIFIER_MAP;

> 


  reply	other threads:[~2019-06-19 13:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19  8:49 [Qemu-devel] [PATCH] memory: do not do out of bound notification Yan Zhao
2019-06-19 13:17 ` Auger Eric [this message]
2019-06-20  1:46   ` Yan Zhao
2019-06-20  4:02   ` Peter Xu
2019-06-20  4:14     ` Yan Zhao
2019-06-20  8:14       ` Peter Xu
2019-06-20  8:13         ` Yan Zhao
2019-06-20  8:35     ` Paolo Bonzini
2019-06-20 10:57       ` Yan Zhao
2019-06-20 12:04         ` Paolo Bonzini
2019-06-20 12:59       ` Peter Xu
2019-06-20 13:04         ` Peter Xu
2019-06-24  5:22           ` Yan Zhao
2019-06-24  6:14             ` Peter Xu
2019-06-20 13:14         ` Paolo Bonzini
2019-06-21  2:36           ` Peter Xu
2019-06-21  7:57         ` Yan Zhao

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=39c4c32b-e34a-8d8f-abbc-ab346ec5bed7@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yan.y.zhao@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.