search for: smmuv2

...e > any specific efficiency measurements 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 v...

...e > any specific efficiency measurements 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 v...

...39;t translate". It's a bit of an edge case for not-really-PCI devices, but FWIW 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...

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

...io-iommu is more widely adopted. > > Thanks, > Jean > > > [1] Diff between current spec and page table sharing draft > (Very rough, missing page fault support and I'd like to rework the > PASID model a bit, but table descriptors p.24-26 for both Arm > SMMUv2 and SMMUv3.) > > http://jpbrucker.net/virtio-iommu/spec-table/diffs/virtio-iommu-pdf-diff-v0.9-v0.10.dev03.pdf > > [2] [RFC v2 00/28] vSMMUv3/pSMMUv3 2 stage VFIO integration > https://www.mail-archive.com/qemu-devel at nongnu.org/msg562369.html

...uest 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. But with the second solution, nested with SMMUv2 isn't supported since it doesn't have context tables. The second solution was considered simpler to implement, so we'll first go with this one. Thanks, Jean >> It requires to factor the guest >>> PASID handling code into a library, which is difficult for SMMU. Luckily &...

Hi Jean, On Tue Oct 24, 2017 at 10:28:59PM +0530, Linu Cherian wrote: > Hi Jean, > Thanks for your reply. > > On Tue Oct 24, 2017 at 09:37:12AM +0100, Jean-Philippe Brucker wrote: > > Hi Linu, > > > > On 24/10/17 07:27, Linu Cherian wrote: > > > Hi Jean, > > > > > > On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote:

...pect that no one would consider it until virtio-iommu is more widely adopted. Thanks, Jean [1] Diff between current spec and page table sharing draft (Very rough, missing page fault support and I'd like to rework the PASID model a bit, but table descriptors p.24-26 for both Arm SMMUv2 and SMMUv3.) http://jpbrucker.net/virtio-iommu/spec-table/diffs/virtio-iommu-pdf-diff-v0.9-v0.10.dev03.pdf [2] [RFC v2 00/28] vSMMUv3/pSMMUv3 2 stage VFIO integration https://www.mail-archive.com/qemu-devel at nongnu.org/msg562369.html

...Physical IOMMU TLB invalidates would get triggered from software for every viommu_unmap(in guest kernel) through Qemu(using vfio ioctls) ? And for SVM case, ASID would be in shared set and explicit TLB invalidates are not required from software ? But with the second > solution, nested with SMMUv2 isn't supported since it doesn't have context > tables. The second solution was considered simpler to implement, so we'll > first go with this one. > > Thanks, > Jean > > >> It requires to factor the guest > >>> PASID handling code into a library...

...Physical IOMMU TLB invalidates would get triggered from software for every viommu_unmap(in guest kernel) through Qemu(using vfio ioctls) ? And for SVM case, ASID would be in shared set and explicit TLB invalidates are not required from software ? But with the second > solution, nested with SMMUv2 isn't supported since it doesn't have context > tables. The second solution was considered simpler to implement, so we'll > first go with this one. > > Thanks, > Jean > > >> It requires to factor the guest > >>> PASID handling code into a library...

...gt;> Jean >>> >>> >>> [1] Diff between current spec and page table sharing draft >>> (Very rough, missing page fault support and I'd like to rework the >>> PASID model a bit, but table descriptors p.24-26 for both Arm >>> SMMUv2 and SMMUv3.) >>> >>> http://jpbrucker.net/virtio-iommu/spec-table/diffs/virtio-iommu-pdf-diff-v0.9-v0.10.dev03.pdf >>> >>> [2] [RFC v2 00/28] vSMMUv3/pSMMUv3 2 stage VFIO integration >>> https://www.mail-archive.com/qemu-devel at nongnu.org/msg56236...

...>> >> Thanks, >> Jean >> >> >> [1] Diff between current spec and page table sharing draft >> (Very rough, missing page fault support and I'd like to rework the >> PASID model a bit, but table descriptors p.24-26 for both Arm >> SMMUv2 and SMMUv3.) >> >> http://jpbrucker.net/virtio-iommu/spec-table/diffs/virtio-iommu-pdf-diff-v0.9-v0.10.dev03.pdf >> >> [2] [RFC v2 00/28] vSMMUv3/pSMMUv3 2 stage VFIO integration >> https://www.mail-archive.com/qemu-devel at nongnu.org/msg562369.html

Hi Jean, Thanks for your reply. On Tue Oct 24, 2017 at 09:37:12AM +0100, Jean-Philippe Brucker wrote: > Hi Linu, > > On 24/10/17 07:27, Linu Cherian wrote: > > Hi Jean, > > > > On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote: > >> This is version 0.5 of the virtio-iommu specification, the paravirtualized > >> IOMMU. This version

Hi Jean, Thanks for your reply. On Tue Oct 24, 2017 at 09:37:12AM +0100, Jean-Philippe Brucker wrote: > Hi Linu, > > On 24/10/17 07:27, Linu Cherian wrote: > > Hi Jean, > > > > On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote: > >> This is version 0.5 of the virtio-iommu specification, the paravirtualized > >> IOMMU. This version

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

...J: ACPI disabled. [ 1.155545] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.157706] SuperH (H)SCI(F) driver initialized [ 1.158125] msm_serial: driver initialized [ 1.159812] arm-smmu 12000000.iommu: probing hardware configuration... [ 1.159841] arm-smmu 12000000.iommu: SMMUv2 with: [ 1.159863] arm-smmu 12000000.iommu: stage 1 translation [ 1.159883] arm-smmu 12000000.iommu: stage 2 translation [ 1.159903] arm-smmu 12000000.iommu: nested translation [ 1.159925] arm-smmu 12000000.iommu: stream matching with 128 register groups [...

...d [ 8.931241] 3100000.serial: ttyS0 at MMIO 0x3100000 (irq = 22, base_baud = 25500000) is a Tegra [ 9.801591] console [ttyS0] enabled [ 9.805436] msm_serial: driver initialized [ 9.810616] arm-smmu 12000000.iommu: probing hardware configuration... [ 9.817131] arm-smmu 12000000.iommu: SMMUv2 with: [ 9.821835] arm-smmu 12000000.iommu: stage 1 translation [ 9.827220] arm-smmu 12000000.iommu: stage 2 translation [ 9.832610] arm-smmu 12000000.iommu: nested translation [ 9.837911] arm-smmu 12000000.iommu: stream matching with 128 register groups [...

...API to pass in the GFP argument, and fix all call sites. Replace iommu_map_atomic(). Audit the "enterprise" iommu drivers to make sure they do the right thing. Intel and S390 ignore the GFP argument and always use GFP_ATOMIC. This is problematic for iommufd anyhow, so fix it. AMD and ARM SMMUv2/3 are already correct. A follow up series will be needed to capture the allocations made when the iommu_domain itself is allocated, which will complete the job. Jason Gunthorpe (8): iommu: Add a gfp parameter to iommu_map() iommu: Remove iommu_map_atomic() iommu: Add a gfp parameter to iomm...

...API to pass in the GFP argument, and fix all call sites. Replace iommu_map_atomic(). Audit the "enterprise" iommu drivers to make sure they do the right thing. Intel and S390 ignore the GFP argument and always use GFP_ATOMIC. This is problematic for iommufd anyhow, so fix it. AMD and ARM SMMUv2/3 are already correct. A follow up series will be needed to capture the allocations made when the iommu_domain itself is allocated, which will complete the job. Jason Gunthorpe (8): iommu: Add a gfp parameter to iommu_map() iommu: Remove iommu_map_atomic() iommu: Add a gfp parameter to iomm...