search for: smmuv3

...ge faults to the guest from >>> the host kernel should be significantly faster than having to go to >>> userspace and back to the kernel. >> >> Fascinating. Any data about host CPU utilization? >> >> Eric what do you think? >> >> Is it true that SMMUv3 is fundmentally slow at the architecture level >> and so a PV interface will always scale better until >> a new hardware interface is designed? > > As far as I understand the figures above correspond to vhost-iommu > against vsmmuv3. In the 2 cases the guest owns stage1 tables...

...Similarly for fault > injection, having the ability to report page faults to the guest from > the host kernel should be significantly faster than having to go to > userspace and back to the kernel. Fascinating. Any data about host CPU utilization? Eric what do you think? Is it true that SMMUv3 is fundmentally slow at the architecture level and so a PV interface will always scale better until a new hardware interface is designed? > > (4) Virtio and vhost endpoints weren't really a priority for the base > virtio-iommu device, we were looking mainly at device pass-through. I...

...ving the ability to report page faults to the guest from >> the host kernel should be significantly faster than having to go to >> userspace and back to the kernel. > > Fascinating. Any data about host CPU utilization? > > Eric what do you think? > > Is it true that SMMUv3 is fundmentally slow at the architecture level > and so a PV interface will always scale better until > a new hardware interface is designed? As far as I understand the figures above correspond to vhost-iommu against vsmmuv3. In the 2 cases the guest owns stage1 tables so the difference come...

...l, so that map/unmap gets directly handled by the guest and only TLB invalidates happens through a virtio-iommu channel. > It requires to factor the guest > > PASID handling code into a library, which is difficult for SMMU. Luckily > > I'm still working on adding PASID code for SMMUv3, so extracting it out of > > the driver isn't a big overhead. The good thing about this solution is > > that it reuses any specification work done for VFIO (and vice versa) and > > any host driver change made for vSMMU/VT-d emulations. > > > > Thanks, > > Je...

...on.org/msg20189.html > > >>> The alternative is to bind PASID tables. > >> > >> Sorry, i didnt get the difference here. > > PASID table is what we call Context Table in SMMU, it's the array > associating a PASID (SSID) to a context descriptor. In the SMMUv3 the > stream table entry (device descriptor) points to a PASID table. Each > context descriptor in the PASID table points to a page directory (pgd). > > So the first solution was for the guest to send a BIND with pasid+pgd, and > let the host deal with the context tables. The second...

...on.org/msg20189.html > > >>> The alternative is to bind PASID tables. > >> > >> Sorry, i didnt get the difference here. > > PASID table is what we call Context Table in SMMU, it's the array > associating a PASID (SSID) to a context descriptor. In the SMMUv3 the > stream table entry (device descriptor) points to a PASID table. Each > context descriptor in the PASID table points to a page directory (pgd). > > So the first solution was for the guest to send a BIND with pasid+pgd, and > let the host deal with the context tables. The second...

...lisi wrote: > > > > > I don't think it should be done this way. Is the goal compile testing > > > IORT code ? > > > > Yes > > > > > If so, why are we forcing it through the SMMU (only because > > > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ? > > > > Because something needs to select it, and SMMU is one of the places > > that are implicitly using it. > > > > It isn't (and shouldn't be) a user selectable kconfig. Currently the > > only thing that selects it is...

...e.com/iommu at lists.linux-foundation.org/msg20189.html >>> The alternative is to bind PASID tables. >> >> Sorry, i didnt get the difference here. PASID table is what we call Context Table in SMMU, it's the array associating a PASID (SSID) to a context descriptor. In the SMMUv3 the stream table entry (device descriptor) points to a PASID table. Each context descriptor in the PASID table points to a page directory (pgd). So the first solution was for the guest to send a BIND with pasid+pgd, and let the host deal with the context tables. The second solution is to send a BI...

...ould you please share the links on this ? > > The alternative is to bind PASID tables. Sorry, i didnt get the difference here. It requires to factor the guest > PASID handling code into a library, which is difficult for SMMU. Luckily > I'm still working on adding PASID code for SMMUv3, so extracting it out of > the driver isn't a big overhead. The good thing about this solution is > that it reuses any specification work done for VFIO (and vice versa) and > any host driver change made for vSMMU/VT-d emulations. > > Thanks, > Jean -- Linu cherian

...ould you please share the links on this ? > > The alternative is to bind PASID tables. Sorry, i didnt get the difference here. It requires to factor the guest > PASID handling code into a library, which is difficult for SMMU. Luckily > I'm still working on adding PASID code for SMMUv3, so extracting it out of > the driver isn't a big overhead. The good thing about this solution is > that it reuses any specification work done for VFIO (and vice versa) and > any host driver change made for vSMMU/VT-d emulations. > > Thanks, > Jean -- Linu cherian

...ments or estimates that you can share? The main motivation for this work is to bring IOMMU virtualization to the ARM world. We don't have any at the moment, and a full ARM SMMU virtualization solution would be counter-productive. We would have to do it for SMMUv2, for the completely orthogonal SMMUv3, and for any future version of the architecture. Doing so in userspace might be acceptable, but then for performance reasons people will want in-kernel emulation of every IOMMU variant out there, which is a maintenance and security nightmare. A single generic vIOMMU is preferable because it reduces...

...ments or estimates that you can share? The main motivation for this work is to bring IOMMU virtualization to the ARM world. We don't have any at the moment, and a full ARM SMMU virtualization solution would be counter-productive. We would have to do it for SMMUv2, for the completely orthogonal SMMUv3, and for any future version of the architecture. Doing so in userspace might be acceptable, but then for performance reasons people will want in-kernel emulation of every IOMMU variant out there, which is a maintenance and security nightmare. A single generic vIOMMU is preferable because it reduces...

On Tue, Nov 27, 2018 at 05:55:20PM +0000, Jean-Philippe Brucker wrote: > On 23/11/2018 21:56, Michael S. Tsirkin wrote: > >> +config VIRTIO_IOMMU > >> + bool "Virtio IOMMU driver" > >> + depends on VIRTIO=y > >> + select IOMMU_API > >> + select INTERVAL_TREE > >> + select ARM_DMA_USE_IOMMU if ARM > >> + help > >>

...non SVM >>> cases. For example, if we need to share the IOMMU page table for >>> a device used in guest kernel, so that map/unmap gets directly handled by the guest >>> and only TLB invalidates happens through a virtio-iommu channel. >> >> Yes for non-SVM in SMMuv3, you still have a context table but with a >> single descriptor, so the interface stays the same. > > So for non SVM case, > guest virtio-iommu driver will program the context descriptor such a way that, > ASID is not in shared set(ASET = 1b) and hence Physical IOMMU TLB invali...

...omplex node of IORT has an ATS attribute, which we can already use. However its scope is the root complex, not individual root ports like with DMAR. I'm not very familiar with NUMA, but it looks like we just need to specify a proximity domain in relation to the SRAT table, for each viommu? The SMMUv3 node in IORT has a 4-bytes "proximity domain" field for this. We can add the same to the VIOT virtio-iommu nodes later, since the structures are extensible. But it might be better to keep the bare minimum information in the FW descriptor, and put the rest in the virtio-iommu. So yes topo...

...check for VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE message types to fix a regression observed with batching hit. Still, the introduction of that check introduced a regression for some users attempting to invalidate the whole ULONG_MAX range by setting the size to 0. This is the case with qemu/smmuv3/vhost integration which does not work anymore. It Looks safe to partially revert the original commit and allow VHOST_IOTLB_INVALIDATE messages with null size. vhost_iotlb_del_range() will compute a correct end iova. Same for vhost_vdpa_iotlb_unmap(). Signed-off-by: Eric Auger <eric.auger at red...

...WIW I can certainly think of several ways to build real hardware like that. As for inadvertent errors leaving out IDs which *should* be in the map, that really depends on the IOMMU/driver implementation - e.g. SMMUv2 with arm-smmu.disable_bypass=0 would treat the device as untranslated, whereas SMMUv3 would always generate a fault upon any transaction due to no valid stream table entry being programmed (not even a bypass one). I reckon it's a sufficiently unusual case that keeping some sort of message probably is worthwhile (at pr_info rather than pr_err) in case someone does hit it by...

...the BIND ioctl is different from the one used by VT-d, so this solution didn't get much appreciation. The alternative is to bind PASID tables. It requires to factor the guest PASID handling code into a library, which is difficult for SMMU. Luckily I'm still working on adding PASID code for SMMUv3, so extracting it out of the driver isn't a big overhead. The good thing about this solution is that it reuses any specification work done for VFIO (and vice versa) and any host driver change made for vSMMU/VT-d emulations. Thanks, Jean

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Here I propose a few ideas for extensions and optimizations. This is all > very exploratory, feel free to correct mistakes and suggest more things. [...] > > II. Page table sharing > ====================== > > 1. Sharing IOMMU page tables > ---------------------------- > >

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > > Here I propose a few ideas for extensions and optimizations. This is all > very exploratory, feel free to correct mistakes and suggest more things. [...] > > II. Page table sharing > ====================== > > 1. Sharing IOMMU page tables > ---------------------------- > >