qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Peter Xu <peterx@redhat.com>
Cc: mst@redhat.com, qemu-devel@nongnu.org, eric.auger@redhat.com,
	alex.williamson@redhat.com, pbonzini@redhat.com,
	bbhushan2@marvell.com
Subject: Re: [PATCH v10 09/10] virtio-iommu: Set supported page size mask
Date: Fri, 23 Oct 2020 09:48:58 +0200	[thread overview]
Message-ID: <20201023074858.GA2265982@myrica> (raw)
In-Reply-To: <20201022205616.GD3208@xz-x1>

On Thu, Oct 22, 2020 at 04:56:16PM -0400, Peter Xu wrote:
> On Thu, Oct 22, 2020 at 06:39:37PM +0200, Jean-Philippe Brucker wrote:
> > So what I'd like to do for next version:
> > 
> > * Set qemu_real_host_page_mask as the default page mask, instead of the
> >   rather arbitrary TARGET_PAGE_MASK.
> 
> Oh, I thought TARGET_PAGE_MASK was intended - kernel committ 39b3b3c9cac1
> ("iommu/virtio: Reject IOMMU page granule larger than PAGE_SIZE", 2020-03-27)
> explicitly introduced a check that virtio-iommu kernel driver will fail
> directly if this psize is bigger than PAGE_SIZE in the guest.  So it sounds
> reasonable to have the default value as PAGE_SIZE (if it's the same as
> TARGET_PAGE_SIZE in QEMU, which seems true?).
> 
> For example, I'm thinking whether qemu_real_host_page_mask could be bigger than
> PAGE_SIZE in the guest in some environments, then it seems virtio-iommu won't
> boot anymore without assigned devices, because that extra check above will
> always fail.

Right, I missed this problem again. Switching to qemu_real_host_page_mask
is probably not the best idea until we solve the host64k-guest4k problem.

> 
> >   Otherwise we cannot hotplug assigned
> >   devices on a 64kB host, since TARGET_PAGE_MASK is pretty much always
> >   4kB.
> > 
> > * Disallow changing the page size. It's simpler and works in
> >   practice if we default to qemu_real_host_page_mask.
> > 
> > * For non-hotplug devices, allow changing the rest of the mask. For
> >   hotplug devices, only warn about it.
> 
> Could I ask what's "the rest of the mask"?

The LSB in the mask defines the page size. The other bits define which
block sizes are supported, for example 2MB and 1GB blocks with a 4k page
size. These are only for optimization, the upper bits of the mask could
also be all 1s. If the guest aligns its mappings on those block sizes,
then the host can use intermediate levels in the page tables resulting in
fewer IOTLB entries.

> On the driver side, I see that
> viommu_domain_finalise() will pick the largest supported page size to use, if
> so then we seem to be quite restricted on what page size we can use.

In Linux iommu_dma_alloc_remap() tries to allocate blocks based on the
page mask (copied by viommu_domain_finalise() into domain->pgsize_bitmap)

> I'm also a bit curious about what scenario we plan to support in this initial
> version, especially for ARM.  For x86, I think it's probably always 4k
> everywhere so it's fairly simple.  Know little on ARM side...

Arm CPUs and SMMU support 4k, 16k and 64k page sizes. I don't think 16k is
used anywhere but some distributions chose 64k (RHEL, I think?), others
4k, so we need to support both.

Unfortunately as noted above host64k-guest4k is not possible without
adding a negotiation mechanism to virtio-iommu, host VFIO and IOMMU
driver.

Thanks,
Jean


  reply	other threads:[~2020-10-23  7:49 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08 17:15 [PATCH v10 00/10] virtio-iommu: VFIO integration Jean-Philippe Brucker
2020-10-08 17:15 ` [PATCH v10 01/10] virtio-iommu: Fix virtio_iommu_mr() Jean-Philippe Brucker
2020-10-16  7:36   ` Auger Eric
2020-10-19 21:36   ` Peter Xu
2020-10-08 17:15 ` [PATCH v10 02/10] virtio-iommu: Store memory region in endpoint struct Jean-Philippe Brucker
2020-10-16  7:37   ` Auger Eric
2020-10-08 17:15 ` [PATCH v10 03/10] virtio-iommu: Add memory notifiers for map/unmap Jean-Philippe Brucker
2020-10-16  7:58   ` Auger Eric
2020-10-22 16:41     ` Jean-Philippe Brucker
2020-10-08 17:15 ` [PATCH v10 04/10] virtio-iommu: Call memory notifiers in attach/detach Jean-Philippe Brucker
2020-10-16  8:05   ` Auger Eric
2020-10-08 17:15 ` [PATCH v10 05/10] virtio-iommu: Add replay() memory region callback Jean-Philippe Brucker
2020-10-16  9:12   ` Auger Eric
2020-10-22 16:42     ` Jean-Philippe Brucker
2020-10-08 17:15 ` [PATCH v10 06/10] virtio-iommu: Add notify_flag_changed() " Jean-Philippe Brucker
2020-10-16  8:18   ` Auger Eric
2020-10-08 17:15 ` [PATCH v10 07/10] memory: Add interface to set iommu page size mask Jean-Philippe Brucker
2020-10-16  9:24   ` Auger Eric
2020-10-22 16:43     ` Jean-Philippe Brucker
2020-10-19 21:36   ` Peter Xu
2020-10-08 17:15 ` [PATCH v10 08/10] vfio: Set IOMMU page size as per host supported page size Jean-Philippe Brucker
2020-10-08 21:22   ` Alex Williamson
2020-10-30 10:26     ` Michael S. Tsirkin
2020-10-30 15:19       ` Jean-Philippe Brucker
2020-10-16  9:25   ` Auger Eric
2020-10-08 17:15 ` [PATCH v10 09/10] virtio-iommu: Set supported page size mask Jean-Philippe Brucker
2020-10-16 13:08   ` Auger Eric
2020-10-22 16:43     ` Jean-Philippe Brucker
2020-10-19 21:35   ` Peter Xu
2020-10-22 16:39     ` Jean-Philippe Brucker
2020-10-22 20:56       ` Peter Xu
2020-10-23  7:48         ` Jean-Philippe Brucker [this message]
2020-10-23 16:47           ` Peter Xu
2020-10-27 17:38             ` Jean-Philippe Brucker
2020-10-30 10:24               ` Michael S. Tsirkin
2020-10-08 17:15 ` [PATCH v10 10/10] vfio: Don't issue full 2^64 unmap Jean-Philippe Brucker
2020-10-08 21:22   ` Alex Williamson
2020-10-30 10:25     ` Michael S. Tsirkin
2020-10-30 17:26       ` Alex Williamson
2020-10-30 18:19         ` Paolo Bonzini
2020-11-02 17:37           ` Alex Williamson
2020-11-02 17:44             ` Paolo Bonzini
2020-11-02 18:00               ` Alex Williamson
2020-10-16  9:47   ` Auger Eric
2020-10-16 13:13 ` [PATCH v10 00/10] virtio-iommu: VFIO integration Auger Eric
2020-10-30 10:27 ` Michael S. Tsirkin
2020-10-30 10:48   ` Jean-Philippe Brucker

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=20201023074858.GA2265982@myrica \
    --to=jean-philippe@linaro.org \
    --cc=alex.williamson@redhat.com \
    --cc=bbhushan2@marvell.com \
    --cc=eric.auger@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).