On Tue, 14 Oct 2025 at 14:22, Daniel P. Berrangé <[email protected]> wrote: > > On Tue, Oct 14, 2025 at 01:20:07PM +0100, Peter Maydell wrote: > > 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 ? > > No, that would be wrong. How about this alternative > > @@ -21,7 +21,9 @@ Virtualization Use Case > The virtualization use case covers cloud and virtual private server (VPS) > hosting, as well as traditional data center and desktop virtualization. > These > use cases rely on hardware virtualization extensions to execute guest code > -safely on the physical CPU at close-to-native speed. > +safely on the physical CPU at close-to-native speed. This use case is > limited > +to the use of versioned machine types, or machine types designed > exclusively > +for virtualization. > > The following entities are untrusted, meaning that they may be buggy or > malicious: > > that wording would bring xen* and microvm into the scope, and so match > your manually curated list.
I think that it's simpler for users if we explicitly list the machines, rather than making them guess whether a machine is "designed exclusively for virtualization". thanks -- PMM
