All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	mst@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org,
	cornelia.huck@de.ibm.com, alex.williamson@redhat.com,
	wexu@redhat.com, vkaplans@redhat.com, dgibson@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/3] memory: add iommu_notify_flag
Date: Wed, 14 Sep 2016 13:43:12 +0800	[thread overview]
Message-ID: <20160914054312.GL3776@pxdev.xzpeter.org> (raw)
In-Reply-To: <20160914040029.GH15077@voom.fritz.box>

On Wed, Sep 14, 2016 at 02:00:29PM +1000, David Gibson wrote:

[...]

> > > > > 
> > > > > > So
> > > > > > IIUC this is a question about "naming" but not the implementations...
> > > > > > I suppose it is really a matter of taste, and both work for me (either
> > > > > > INVALIDATION/CHANGE or UNMAP/MAP).
> > > > > 
> > > > > No.. it is a question of implementation.  My point is that I don't
> > > > > think the new permission is sufficient information to let you know if
> > > > > a notification is necessary.  You need to know if there was an
> > > > > existing mapping at that IOBA.
> > > > 
> > > > My understanding is that we don't need to know that. Because IIUC
> > > > there are only map_page() and unmap_page() in guest IOMMU driver
> > > > (please check dma_map_ops in kernel). There is no chance for anyone to
> > > > "change" the content of the mapping, unless it calls unmap_page() then
> > > > with a map_page(). In that case, we'll have two IOTLB invalidation
> > > > requests.
> > > 
> > > That's assuming a Linux guest using the current guest IOMMU model.
> > > 
> > > I don't think we do so in practice, but the PAPR hypercall interface
> > > allows in-place changing of a mapping.  The interface is just "set
> > > this IOPTE to this value".
> > 
> > I see. Even if so, QEMU IOMMU emulation codes can convert one CHANGE
> > request into UNMAP and a continuous MAP, right?
> 
> Yes, I guess so.  Why is that preferable to issuing a single
> notification to both "map" and "unmap" listeners though?

So I think we should be talking about the same thing here (please
correct me if I am wrong...). Please review v4 of this series and see
whether that works (I renamed CHANGE into MAP, so there will be
MAP/UNMAP, and I think things are clearer with it).

Thanks!

-- peterx

  reply	other threads:[~2016-09-14  5:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-05  7:21 [Qemu-devel] [PATCH 0/3] memory: add IOMMU notifier type Peter Xu
2016-09-05  7:21 ` [Qemu-devel] [PATCH 1/3] memory: add one flag for IOMMU notifier Peter Xu
2016-09-05  7:21 ` [Qemu-devel] [PATCH 2/3] memory: add iommu_notify_flag Peter Xu
2016-09-05  8:04   ` Paolo Bonzini
2016-09-05  8:38     ` Peter Xu
2016-09-05  9:56       ` Paolo Bonzini
2016-09-06  5:27         ` Peter Xu
2016-09-06  7:51           ` Paolo Bonzini
2016-09-06  8:17             ` Peter Xu
2016-09-06  8:19               ` Paolo Bonzini
2016-09-06 10:31                 ` Peter Xu
2016-09-07  5:44                   ` David Gibson
2016-09-07  6:34                     ` Peter Xu
2016-09-07  6:41                       ` David Gibson
2016-09-08  9:07                         ` Peter Xu
2016-09-12  1:26                           ` David Gibson
2016-09-12  5:13                             ` Peter Xu
2016-09-14  4:00                               ` David Gibson
2016-09-14  5:43                                 ` Peter Xu [this message]
2016-09-06  5:18       ` David Gibson
2016-09-06  5:55         ` Peter Xu
2016-09-06  5:12   ` David Gibson
2016-09-06  5:33     ` Peter Xu
2016-09-05  7:21 ` [Qemu-devel] [PATCH 3/3] intel_iommu: allow IOMMU_NONE typed notifiers Peter Xu
2016-09-06  5:06 ` [Qemu-devel] [PATCH 0/3] memory: add IOMMU notifier type David Gibson
2016-09-06  5:49   ` Peter Xu
2016-09-06  6:26     ` Jason Wang
2016-09-07  4:38       ` David Gibson

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=20160914054312.GL3776@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgibson@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vkaplans@redhat.com \
    --cc=wexu@redhat.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.