Messages in this thread | | | Date | Fri, 10 Mar 2023 11:25:04 -0400 | From | Jason Gunthorpe <> | Subject | Re: [PATCH v1 02/14] iommufd: Add nesting related data structures for ARM SMMUv3 |
| |
On Fri, Mar 10, 2023 at 02:52:42PM +0000, Robin Murphy wrote: > On 2023-03-09 21:01, Jason Gunthorpe wrote: > > > For a lot of SMMUv3 implementations that have a single queue and for > > > other architectures, we can do better than hardware emulation. > > > > How is using a SW emulated virtio formatted queue better than using a > > SW emulated SMMUv3 ECMDQ? > > Since it's not been said, the really big thing is that virtio explicitly > informs the host whenever the guest maps something. Emulating SMMUv3 means > the host has to chase all the pagetable pointers in guest memory and trap > writes such that it has visibility of invalid->valid transitions and can > update the physical shadow pagetable correspondingly.
Sorry, I mean in the context of future virtio-iommu that is providing nested translation.
eg why would anyone want to use virtio to provide SMMUv3 based HW accelerated nesting?
Jean suggested that the invalidation flow for virtio-iommu could be faster because it is in kernel, but I'm saying that we could also make the SMMUv3 invalidation in-kernel with the same basic technique. (and actively wondering if we should put more focus on that)
I understand the appeal of the virtio scheme with its current map/unmap interface.
I could also see some appeal of a simple virtio-iommu SVA that could point map a CPU page table as an option. The guest already has to know how to manage these anyhow so it is nicely general.
If iommufd could provide a general cross-driver API to set exactly that scenario up then VMM code could also be general. That seems prettty interesting.
But if the plan is to expose more detailed stuff like the CD or GCR3 PASID tables as something the guest has to manipulate and then a bunch of special invalidation to support that, and VMM code to back it, then I'm questioning the whole point. We lost the generality.
Just use the normal HW accelerated SMMUv3 nesting model instead.
If virtio-iommu SVA is really important for ARM then I'd suggest SMMUv3 should gain a new HW capability to allowed the CD table to be in hypervisor memory so it works consistently for virtio-iommu SVA.
Jason
| |