Hi,
On 3/17/25 9:19 PM, Nicolin Chen wrote: > On Mon, Mar 17, 2025 at 04:24:53PM -0300, Jason Gunthorpe wrote: >> On Mon, Mar 17, 2025 at 12:10:19PM -0700, Nicolin Chen wrote: >>> Another question: how does an emulated device work with a vSMMUv3? >>> I could imagine that all the accel steps would be bypassed since >>> !sdev->idev. Yet, the emulated iotlb should cache its translation >>> so we will need to flush the iotlb, which will increase complexity >>> as the TLBI command dispatching function will need to be aware what >>> ASID is for emulated device and what is for vfio device.. >> I think you should block it. We already expect different vSMMU's >> depending on the physical SMMU under the PCI device, it makes sense >> that a SW VFIO device would have it's own, non-accelerated, vSMMU >> model in the guest. > Yea, I agree and it'd be cleaner for an implementation separating > them. > > In my mind, the general idea of "accel=on" is also to keep things > in a more efficient way: passthrough devices go to HW-accelerated > vSMMUs (separated PCIE buses), while emulated ones go to a vSMMU- > bypassed (PCIE0). Originally a specific SMMU device was needed to opt in for MSI reserved region ACPI IORT description which are not needed if you don't rely on S1+S2. However if we don't rely on this trick this was not even needed with legacy integration (https://patchwork.kernel.org/project/qemu-devel/cover/20180921081819.9203-1-eric.au...@redhat.com/). Nevertheless I don't think anything prevents the acceleration granted device from also working with virtio/vhost devices for instance unless you unplug the existing infra. The translation and invalidation just should use different control paths (explicit translation requests, invalidation notifications towards vhost, ...). Again, what does legitimate to have different qemu devices for the same IP? I understand that it simplifies the implementation but I am not sure this is a good reason. Nevertheless it worth challenging. What is the plan for intel iommu? Will we have 2 devices, the legacy device and one for nested? Thanks Eric > > Though I do see the point from QEMU prospective that user may want > to start a VM with HW-accelerated vSMMU for one passthrough device > using a simple setup without caring about the routing via command. > > Thanks > Nicolin >
