qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Eugenio Perez Martin <eperezma@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Yan Zhao <yan.y.zhao@intel.com>,
	Juan Quintela <quintela@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Eric Auger <eric.auger@redhat.com>,
	Avi Kivity <avi@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [RFC v3 0/1] memory: Delete assertion in memory_region_unregister_iommu_notifier
Date: Tue, 11 Aug 2020 15:27:57 -0400	[thread overview]
Message-ID: <20200811192757.GB6353@xz-x1> (raw)
In-Reply-To: <CAJaqyWf24F8ERAuvYj+0Xv=+cYj4v1MCmvCmQFTqcfLVYYCVuQ@mail.gmail.com>

Hi, Eugenio,

On Tue, Aug 11, 2020 at 08:10:44PM +0200, Eugenio Perez Martin wrote:
> Using this patch as a reference, I'm having problems to understand:
> 
> - I'm not sure that the flag name expresses clearly the notifier capability.

The old code is kind of messed up for dev-iotlb invalidations, by always
sending UNMAP notifications for both iotlb and dev-iotlb invalidations.

Now if we introduce the new DEV_IOTLB type, we can separate the two:

  - We notify IOMMU_NOTIFIER_UNMAP for iotlb invalidations

  - We notify IOMMU_NOTIFIER_DEV_IOTLB for dev-iotlb invalidations

Vhost should always be with ats=on when vIOMMU enabled, so it will enable
device iotlb.  Then it does not need iotlb (UNMAP) invalidation any more
because they'll normally be duplicated (one is to invalidate vIOMMU cache, one
is to invalidate device cache).

Also, we can drop UNMAP type for vhost if we introduce DEV_IOTLB.  It works
just like on the real hardwares - the device won't be able to receive iotlb
invalidation messages, but only device iotlb invalidation messages.  Here
vhost (or, virtio-pci) is the device.

> - What would be the advantages of using another field (NotifierType?)
> in the notifier to express that it accepts arbitrary ranges for
> unmapping? (If I understood correctly Jason's proposal)

(Please refer to above too..)

> - Is it possible (or advisable) to skip all the page splitting in
> vtd_page_walk if the memory range notifier supports these arbitrary
> ranges? What would be the disadvantages? (Maybe in a future patch). It
> seems it is advisable to me, but I would like to double confirm.

vtd_page_walk is not used for dev-iotlb, we don't need to change that.  We also
want to explicitly keep the page granularity of vtd_page_walk for the other
IOMMU notifiers, e.g. vfio.

Though we'll need to modify vtd_process_device_iotlb_desc() to only send
notifications to the notifiers that registered with DEV_IOTLB flag.

Hope it helps..

Thanks,

-- 
Peter Xu



  reply	other threads:[~2020-08-11 19:28 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-26  6:41 [RFC v2 0/1] memory: Delete assertion in memory_region_unregister_iommu_notifier Eugenio Pérez
2020-06-26  6:41 ` [RFC v2 1/1] " Eugenio Pérez
2020-06-26 21:29   ` Peter Xu
2020-06-27  7:26     ` Yan Zhao
2020-06-27 12:57       ` Peter Xu
2020-06-28  1:36         ` Yan Zhao
2020-06-28  7:03     ` Jason Wang
2020-06-28 14:47       ` Peter Xu
2020-06-29  5:51         ` Jason Wang
2020-06-29 13:34           ` Peter Xu
2020-06-30  2:41             ` Jason Wang
2020-06-30  8:29               ` Jason Wang
2020-06-30  9:21                 ` Michael S. Tsirkin
2020-06-30  9:23                   ` Jason Wang
2020-06-30 15:20                     ` Peter Xu
2020-07-01  8:11                       ` Jason Wang
2020-07-01 12:16                         ` Peter Xu
2020-07-01 12:30                           ` Jason Wang
2020-07-01 12:41                             ` Peter Xu
2020-07-02  3:00                               ` Jason Wang
2020-06-30 15:39               ` Peter Xu
2020-07-01  8:09                 ` Jason Wang
2020-07-02  3:01                   ` Jason Wang
2020-07-02 15:45                     ` Peter Xu
2020-07-03  7:24                       ` Jason Wang
2020-07-03 13:03                         ` Peter Xu
2020-07-07  8:03                           ` Jason Wang
2020-07-07 19:54                             ` Peter Xu
2020-07-08  5:42                               ` Jason Wang
2020-07-08 14:16                                 ` Peter Xu
2020-07-09  5:58                                   ` Jason Wang
2020-07-09 14:10                                     ` Peter Xu
2020-07-10  6:34                                       ` Jason Wang
2020-07-10 13:30                                         ` Peter Xu
2020-07-13  4:04                                           ` Jason Wang
2020-07-16  1:00                                             ` Peter Xu
2020-07-16  2:54                                               ` Jason Wang
2020-07-17 14:18                                                 ` Peter Xu
2020-07-20  4:02                                                   ` Jason Wang
2020-07-20 13:03                                                     ` Peter Xu
2020-07-21  6:20                                                       ` Jason Wang
2020-07-21 15:10                                                         ` Peter Xu
2020-08-03 16:00                         ` Eugenio Pérez
2020-08-04 20:30                           ` Peter Xu
2020-08-05  5:45                             ` Jason Wang
2020-08-11 17:01     ` Eugenio Perez Martin
2020-08-11 17:10       ` Eugenio Perez Martin
2020-06-29 15:05 ` [RFC v2 0/1] " Paolo Bonzini
2020-07-03  7:39   ` Eugenio Perez Martin
2020-07-03 10:10     ` Paolo Bonzini
2020-08-11 17:55 ` [RFC v3 " Eugenio Pérez
2020-08-11 17:55   ` [RFC v3 1/1] memory: Skip bad range assertion if notifier supports arbitrary masks Eugenio Pérez
2020-08-12  2:24     ` Jason Wang
2020-08-12  8:49       ` Eugenio Perez Martin
2020-08-18 14:24         ` Eugenio Perez Martin
2020-08-19  7:15           ` Jason Wang
2020-08-19  8:22             ` Eugenio Perez Martin
2020-08-19  9:36               ` Jason Wang
2020-08-19 15:50             ` Peter Xu
2020-08-20  2:28               ` Jason Wang
2020-08-21 14:12                 ` Peter Xu
2020-09-01  3:05                   ` Jason Wang
2020-09-01 19:35                     ` Peter Xu
2020-09-02  5:13                       ` Jason Wang
2020-08-11 18:10   ` [RFC v3 0/1] memory: Delete assertion in memory_region_unregister_iommu_notifier Eugenio Perez Martin
2020-08-11 19:27     ` Peter Xu [this message]
2020-08-12 14:33       ` Eugenio Perez Martin
2020-08-12 21:12         ` Peter Xu

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=20200811192757.GB6353@xz-x1 \
    --to=peterx@redhat.com \
    --cc=avi@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --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 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).