qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
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 v11 09/10] virtio-iommu: Set supported page size mask
Date: Mon, 2 Nov 2020 17:47:25 -0500	[thread overview]
Message-ID: <20201102224725.GF20600@xz-x1> (raw)
In-Reply-To: <20201030180510.747225-10-jean-philippe@linaro.org>

On Fri, Oct 30, 2020 at 07:05:09PM +0100, Jean-Philippe Brucker wrote:
> From: Bharat Bhushan <bbhushan2@marvell.com>
> 
> The virtio-iommu device can deal with arbitrary page sizes for virtual
> endpoints, but for endpoints assigned with VFIO it must follow the page
> granule used by the host IOMMU driver.
> 
> Implement the interface to set the vIOMMU page size mask, called by VFIO
> for each endpoint. We assume that all host IOMMU drivers use the same
> page granule (the host page granule). Override the page_size_mask field
> in the virtio config space.

(Nit: Seems slightly mismatched with the code below)

[...]

> +    /*
> +     * After the machine is finalized, we can't change the mask anymore. If by
> +     * chance the hotplugged device supports the same granule, we can still
> +     * accept it. Having a different masks is possible but the guest will use
> +     * sub-optimal block sizes, so warn about it.
> +     */
> +    if (qdev_hotplug) {
> +        int new_granule = ctz64(new_mask);
> +        int cur_granule = ctz64(cur_mask);
> +
> +        if (new_granule != cur_granule) {
> +            error_setg(errp, "virtio-iommu page mask 0x%"PRIx64
> +                       " is incompatible with mask 0x%"PRIx64, cur_mask,
> +                       new_mask);
> +            return -1;
> +        } else if (new_mask != cur_mask) {
> +            warn_report("virtio-iommu page mask 0x%"PRIx64
> +                        " does not match 0x%"PRIx64, cur_mask, new_mask);

IMHO, new_mask!=cur_mask is ok, as long as it's a superset of reported
cur_mask, then it'll still guarantee to work.

Meanwhile, checking against granule seems not safe enough if the guest driver
started to use huge pages in iommu pgtables...

In summary:

    if (qdev_hotplug) {
        if ((new_mask & cur_mask) == cur_mask) {
            /* Superset of old mask; we're good.  Keep the old mask since same */
            return 0;
        } else {
            /* Guest driver can use any psize in cur_mask, not safe to continue */
            error_setg(...);
            return -1;
        }
    }

Maybe we can also work on top too (if this is the only reason to repost,
especially if Michael would like to pick this up sooner), so I just raise this
up.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2020-11-02 22:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-30 18:05 [PATCH v11 00/10] virtio-iommu: VFIO integration Jean-Philippe Brucker
2020-10-30 18:05 ` [PATCH v11 01/10] virtio-iommu: Fix virtio_iommu_mr() Jean-Philippe Brucker
2020-10-30 18:05 ` [PATCH v11 02/10] virtio-iommu: Store memory region in endpoint struct Jean-Philippe Brucker
2020-10-30 18:05 ` [PATCH v11 03/10] virtio-iommu: Add memory notifiers for map/unmap Jean-Philippe Brucker
2020-10-30 18:05 ` [PATCH v11 04/10] virtio-iommu: Call memory notifiers in attach/detach Jean-Philippe Brucker
2020-10-30 18:05 ` [PATCH v11 05/10] virtio-iommu: Add replay() memory region callback Jean-Philippe Brucker
2020-10-30 18:05 ` [PATCH v11 06/10] virtio-iommu: Add notify_flag_changed() " Jean-Philippe Brucker
2020-10-30 18:05 ` [PATCH v11 07/10] memory: Add interface to set iommu page size mask Jean-Philippe Brucker
2020-10-30 18:05 ` [PATCH v11 08/10] vfio: Set IOMMU page size as per host supported page size Jean-Philippe Brucker
2020-10-30 18:05 ` [PATCH v11 09/10] virtio-iommu: Set supported page size mask Jean-Philippe Brucker
2020-11-02 22:47   ` Peter Xu [this message]
2020-11-03 16:32     ` Jean-Philippe Brucker
2020-11-03 16:44       ` Peter Xu
2020-10-30 18:05 ` [PATCH v11 10/10] vfio: Don't issue full 2^64 unmap 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=20201102224725.GF20600@xz-x1 \
    --to=peterx@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=bbhushan2@marvell.com \
    --cc=eric.auger@redhat.com \
    --cc=jean-philippe@linaro.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@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).