On Mon, 13 Oct 2025 at 12:47, Daniel P. Berrangé <[email protected]> wrote: > With a very minimal wording tweak our current defined policy could > avoid being a blocker for enabling KVM in imx8mp-evk. In > > https://www.qemu.org/docs/master/system/security.html > > where it describes the "virtualization use case", we could simply > tweak it to always require a versioned machine type > > Change > > "These use cases rely on hardware virtualization extensions > to execute guest code safely on the physical CPU at close- > to-native speed." > > To say > > "These use cases apply to versioned machine types when used > in combination with hardware virtualization extensions > to execute guest code safely on the physical CPU at close- > to-native speed"
With the suggested changes listed elsewhere in this thread, my current manually curated list of machines is: aarch64 ``virt`` i386, x86_64 ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35`` s390x ``s390-ccw-virtio`` loongarch64: ``virt`` ppc64: ``pseries`` riscv32, riscv64: ``virt`` If we say "versioned machine type", that puts these machines outside the "supported" boundary: i386, x86_64 ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh`` loongarch64: ``virt`` riscv32, riscv64: ``virt`` I can certainly see the argument for loongarch64 and maybe even riscv[*] still being "not supported for production security-boundary stuff", but do we really want to say that the Xen machine types and microvm aren't suitable for VM use ? [*] Could somebody from riscv or loongarch maintainers say whether they think these machines should be on the "security supported" list or not yet ? thanks -- PMM
