[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support

From: Auger Eric
Subject: Re: [PATCH] vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support
Date: Mon, 8 Feb 2021 21:23:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0


On 2/7/21 3:47 PM, Peter Xu wrote:
> Hi, Kevin,
> On Sun, Feb 07, 2021 at 09:04:55AM +0000, Tian, Kevin wrote:
>>> From: Peter Xu
>>> Sent: Friday, February 5, 2021 11:31 PM
>>>>>> 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.
>> dev-iotlb is useful in two manners.First, it's a functional prerequisite for
>> supporting I/O page faults.
If I understand correctly, the stall model of the ARM SMMU allows IOPF I
guess without dev-iotlb (ATS). However indeed PRI requires ATS.
> Is this also a hard requirement for virtio-iommu, which is not a real hardware
> after all?
>> Second, it has performance benefit as you don't
>> need to contend the lock of global iotlb.
> Hmm.. are you talking about e.g. vt-d driver or virtio-iommu?
> Assuming it's about vt-d, qi_flush_dev_iotlb() will still call 
> qi_submit_sync()
> and taking the same global QI lock, as I see it, or I could be wrong 
> somewhere.
> I don't see where dev-iotlb has a standalone channel for delivery.
> For virtio-iommu, we haven't defined dev-iotlb, right?
no there is no such feature at the moment. If my understanding is
correct this would only make sense when protecting a HW device. In that
case the underlying physical IOMMU would be programmed for ATS.

When protecting a virtio device (inc. vhost) what would be the adventage
over the current standard unmap notifier?


  Sorry I missed things
> when I completely didn't follow virtio-iommu recently - let's say if
> virtio-iommu in the future can support per-dev dev-iotlb queue so it doesn't
> need a global lock, what if we make it still per-device but still delivering
> iotlb message?  Again, it's still a bit unclear to me why a full emulation
> iommu would need that definition of "iotlb" and "dev-iotlb".
>>> 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.
>> Didn't get this point. Hardware dev-iotlb is updated by hardware (between
>> the device and the IOMMU). How could software convert a virtual iotlb
>> entry into hardware dev-iotlb?
> I mean if virtio-iommu must be run in a guest, then we can trap that message
> first, right?  If there're assigned device in the guest, we must convert that
> invalidation to whatever message required for the host, that seems to not
> require the virtio-iommu to have dev-iotlb knowledge, still?
> Thanks,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]