All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Peter Xu <peterx@redhat.com>, qemu-devel@nongnu.org
Cc: Eric Auger <eric.auger@redhat.com>,
	Eugenio Perez Martin <eperezma@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support
Date: Fri, 5 Feb 2021 11:16:39 +0800	[thread overview]
Message-ID: <2382a93d-41c1-24fd-144f-87ee18171bc9@redhat.com> (raw)
In-Reply-To: <20210204191228.187550-1-peterx@redhat.com>


On 2021/2/5 上午3:12, Peter Xu wrote:
> Previous work on dev-iotlb message broke vhost on either SMMU


Have a quick git grep and it looks to me v3 support ATS and have command 
for device iotlb (ATC) invalidation.


> or virtio-iommu
> since dev-iotlb (or PCIe ATS)


We may need to add this in the future.


> is not yet supported for those archs.


Rethink about this, it looks to me the point is that we should make 
vhost work when ATS is disabled like what ATS spec defined:

"""

ATS is enabled through a new Capability and associated configuration 
structure.  To enable 15 ATS, software must detect this Capability and 
enable the Function to issue ATS TLP.  If a Function is not enabled, the 
Function is required not to issue ATS Translation Requests and is 
required to issue all DMA Read and Write Requests with the TLP AT field 
set to “untranslated.”

"""

Maybe we can add this in the commit log.


>
> An initial idea is that we can let IOMMU to export this information to vhost so
> that vhost would know whether the vIOMMU would support dev-iotlb, then vhost
> can conditionally register to dev-iotlb or the old iotlb way.  We can work
> based on some previous patch to introduce PCIIOMMUOps as Yi Liu proposed [1].
>
> However it's not as easy as I thought since vhost_iommu_region_add() does not
> have a PCIDevice context at all since it's completely a backend.  It seems
> non-trivial to pass over a PCI device to the backend during init.  E.g. when
> the IOMMU notifier registered hdev->vdev is still NULL.
>
> To make the fix smaller and easier, this patch goes the other way to leverage
> the flag_changed() hook of vIOMMUs so that SMMU and virtio-iommu can trap the
> dev-iotlb registration and fail it.  Then vhost could try the fallback solution
> as using UNMAP invalidation for it's translations.
>
> [1] https://lore.kernel.org/qemu-devel/1599735398-6829-4-git-send-email-yi.l.liu@intel.com/
>
> Reported-by: Eric Auger <eric.auger@redhat.com>
> Fixes: b68ba1ca57677acf870d5ab10579e6105c1f5338
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Tested-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>   hw/arm/smmuv3.c          |  5 +++++
>   hw/virtio/vhost.c        | 13 +++++++++++--
>   hw/virtio/virtio-iommu.c |  5 +++++
>   3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index 98b99d4fe8e..bd1f97000d9 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -1497,6 +1497,11 @@ static int smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu,
>       SMMUv3State *s3 = sdev->smmu;
>       SMMUState *s = &(s3->smmu_state);
>   
> +    if (new & IOMMU_NOTIFIER_DEVIOTLB_UNMAP) {
> +        error_setg(errp, "SMMUv3 does not support dev-iotlb yet");
> +        return -EINVAL;
> +    }
> +
>       if (new & IOMMU_NOTIFIER_MAP) {
>           error_setg(errp,
>                      "device %02x.%02x.%x requires iommu MAP notifier which is "
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index 28c7d781721..6e17d631f77 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -704,6 +704,7 @@ static void vhost_iommu_region_add(MemoryListener *listener,
>       Int128 end;
>       int iommu_idx;
>       IOMMUMemoryRegion *iommu_mr;
> +    int ret;
>   
>       if (!memory_region_is_iommu(section->mr)) {
>           return;
> @@ -726,8 +727,16 @@ static void vhost_iommu_region_add(MemoryListener *listener,
>       iommu->iommu_offset = section->offset_within_address_space -
>                             section->offset_within_region;
>       iommu->hdev = dev;
> -    memory_region_register_iommu_notifier(section->mr, &iommu->n,
> -                                          &error_fatal);
> +    ret = memory_region_register_iommu_notifier(section->mr, &iommu->n, NULL);
> +    if (ret) {
> +        /*
> +         * Some vIOMMUs do not support dev-iotlb yet.  If so, try to use the
> +         * UNMAP legacy message
> +         */
> +        iommu->n.notifier_flags = IOMMU_NOTIFIER_UNMAP;
> +        memory_region_register_iommu_notifier(section->mr, &iommu->n,
> +                                              &error_fatal);
> +    }
>       QLIST_INSERT_HEAD(&dev->iommu_list, iommu, iommu_next);
>       /* TODO: can replay help performance here? */
>   }
> diff --git a/hw/virtio/virtio-iommu.c b/hw/virtio/virtio-iommu.c
> index 6b9ef7f6b2b..c2883a2f6c8 100644
> --- a/hw/virtio/virtio-iommu.c
> +++ b/hw/virtio/virtio-iommu.c
> @@ -893,6 +893,11 @@ static int virtio_iommu_notify_flag_changed(IOMMUMemoryRegion *iommu_mr,
>                                               IOMMUNotifierFlag new,
>                                               Error **errp)
>   {
> +    if (new & IOMMU_NOTIFIER_DEVIOTLB_UNMAP) {
> +        error_setg(errp, "Virtio-iommu does not support dev-iotlb yet");
> +        return -EINVAL;
> +    }
> +
>       if (old == IOMMU_NOTIFIER_NONE) {
>           trace_virtio_iommu_notify_flag_add(iommu_mr->parent_obj.name);
>       } else if (new == IOMMU_NOTIFIER_NONE) {


Patch looks good. I wonder whether we should fix intel when ATS is disabled.

Thanks



  reply	other threads:[~2021-02-05  3:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04 19:12 [PATCH] vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support Peter Xu
2021-02-05  3:16 ` Jason Wang [this message]
2021-02-05  8:33   ` Auger Eric
2021-02-05 15:31     ` Peter Xu
2021-02-07  9:04       ` Tian, Kevin
2021-02-07 14:47         ` Peter Xu
2021-02-08  7:03           ` Tian, Kevin
2021-02-08 18:26             ` Peter Xu
2021-02-10  4:05               ` Jason Wang
2021-02-08 20:23           ` Auger Eric
2021-02-08  3:21       ` Jason Wang
2021-02-08 18:37         ` Peter Xu
2021-02-08 20:30           ` Auger Eric
2021-02-09  3:12           ` Jason Wang
2021-02-09 17:15             ` Auger Eric
2021-02-09 19:46               ` 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=2382a93d-41c1-24fd-144f-87ee18171bc9@redhat.com \
    --to=jasowang@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=mst@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 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.