On 2025/6/17 21:11, Jason Gunthorpe wrote:
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.
hmmm. intel iommu driver makes sm_on by default since v5.15. So if guest
configs sm_off, that means it wants it. For the kernel <5.15, yes it will
use legacy mode if it has not configured sm_on explicitly. So this seems
not an issue.
Actually, as I explained in the first hunk of [1], there is no issue with
the legacy mode support. :)
[1]
https://lore.kernel.org/qemu-devel/20250521111452.3316354-1-zhenzhong.d...@intel.com/T/#m4c8fa70742001d4c22b3c297e240a2151d2c617f
What is desirable is to make this automatic and ensure we stay in the
nesting configuration only.
yes, once QEMU supports nested translation based vIOMMU, it's better to use
sm_on instead of legacy. I think for the kernels >= 5.15, this automation
has already been achieved since sm is default on.
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.
got it. yes, it's all about backward compatible support.
Regards,
Yi Liu