On 2025/10/14 下午8:20, 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 ?
[*] Could somebody from riscv or loongarch maintainers
say whether they think these machines should be on the
"security supported" list or not yet ?
yes, loongarch virt machine with kvm accel should be security supported.
Also in next version we consider to add versioned machine type with
loongarch architecture.
Regards
Bibo Mao
thanks
-- PMM
