All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Auger Eric <eric.auger@redhat.com>
Cc: Jean-Philippe Brucker <Jean-Philippe.Brucker@arm.com>,
	Eugenio Perez Martin <eperezma@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	qemu-devel@nongnu.org, "Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support
Date: Fri, 5 Feb 2021 10:31:07 -0500	[thread overview]
Message-ID: <20210205153107.GX6468@xz-x1> (raw)
In-Reply-To: <213acf9a-d1c0-3a1d-4846-877d90fadc03@redhat.com>

On Fri, Feb 05, 2021 at 09:33:29AM +0100, Auger Eric wrote:
> Hi,
> 
> On 2/5/21 4:16 AM, Jason Wang wrote:
> > 
> > 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.
> 
> 
> Yes I will do that. Should not be a big deal.

Great, thanks.

> > 
> > 
> >> or virtio-iommu
> >> since dev-iotlb (or PCIe ATS)
> > 
> > 
> > We may need to add this in the future.
> added Jean-Philippe in CC

So that's the part I'm unsure about..  Since everybody is cced so maybe good
time to ask. :)

The thing is I'm still not clear on whether dev-iotlb is useful for a full
emulation environment and how that should differ from a normal iotlb, since
after all normal iotlb will be attached with device information too.

For real hardwares, they make sense because they ask for two things: iotlb is
for IOMMU, but dev-iotlb is for the device cache.  For emulation environment
(virtio-iommu is the case) do we really need that complexity?

Note that even if there're assigned devices under virtio-iommu in the future,
we can still isolate that and iiuc we can easily convert an iotlb (from
virtio-iommu) into a hardware IOMMU dev-iotlb no matter what type of IOMMU is
underneath the vIOMMU.

> > 
> > 
> >> 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.

I saw Michael was super fast on handling this patch and already got it in a
pull, so I may not directly post a new version.  But I'll add it if I'll post a
new version.

[...]

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

I'm not sure I remember it right, but we seem to have similar discussion
previously on "what if the user didn't specify ats=on" - I think at that time
the conclusion was that we ignore the failure since that's not a valid
configuration for qemu.

But I agree it would be nicer to be able to fallback.

The other issue I'm worried is (I think I mentioned it somewhere, but just to
double confirm): I'd like to make sure SMMU and virtio-iommu are the only IOMMU
platform that will use vhost.  Otherwise IIUC we need to fix those vIOMMUs too.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2021-02-05 15:34 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
2021-02-05  8:33   ` Auger Eric
2021-02-05 15:31     ` Peter Xu [this message]
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=20210205153107.GX6468@xz-x1 \
    --to=peterx@redhat.com \
    --cc=Jean-Philippe.Brucker@arm.com \
    --cc=eperezma@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@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.