On Tue, Jun 17, 2025 at 09:03:32PM +0800, Yi Liu wrote: > > I suggest fixing the Linux driver to refuse to run in sm_on mode if > > the HW supports scalable mode and ecap_slts = false. That may not be > > 100% spec compliant but it seems like a reasonable approach. > > running sm_on with only ecap_flts==true is what we want here. We want > the guest use stage-1 page table hence it can be used by hw under the > nested translation mode. While this page table is only available in sm_on > mode. > > If we want to drop the legacy mode usage in virtualization environment, we > might let linux iommu driver refuse running legacy mode while ecap_slts is > false. I suppose HW is going to advertise both ecap_slts and ecap_flts. So > this will just let guest get rid of using legacy mode. > > But this is not necessary so far. As the discussion going here, we intend > to reuse the GPA HWPT allocated by VFIO container as well.[1] This is now > aligned with Nic and Shameer.
I think it is an issue, nobody really wants to accidently start supporting and using shadow mode just because the VM is misconfigured. What is desirable is to make this automatic and ensure we stay in the nesting configuration only. > > ARM is cleaner because it doesn't have these drivers issues. qemu can > > reliably say not to use the S2 and all the existing guest kernels will > > obey that. > > out of curious, does SMMU have legacy mode or a given version of SMMU > only supports either legacy mode or newer mode? The SMMUv3 spec started out with definitions for S1 and S2 as well as capability bits for them at day 0. So it never had this backward compatible problem where we want to remove something that was a mandatory part of the specification. Jason
