[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: Tian, Kevin
Subject: RE: [PATCH] vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support
Date: Sun, 7 Feb 2021 09:04:55 +0000

> 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. Second, it has performance benefit as you don't
need to contend the lock of global 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?


reply via email to

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