On 5/10/26 15:23, Daniel P. Berrangé wrote:
On Mon, Oct 05, 2026 at 03:06:08PM +0200, Philippe Mathieu-Daudé wrote:
Hi,
On 11/9/26 16:36, Daniel P. Berrangé wrote:
The versioned machine types are typically present for use in
virtualization use cases and can be expected to provide a security
barrier. The only exceptions are the m68k versioned machine types
which are only used with TCG. There are also a handful of other
machines declared secure in docs/system/security.rst, notably
the Xen machine variants and microvm.
Signed-off-by: Daniel P. Berrangé <[email protected]>
---
hw/arm/virt.c | 1 +
hw/arm/xen-pvh.c | 1 +
hw/i386/microvm.c | 1 +
hw/i386/pc_piix.c | 4 ++--
hw/i386/xen/xen-pvh.c | 1 +
hw/loongarch/virt.c | 2 ++
hw/ppc/spapr.c | 1 +
hw/riscv/virt.c | 1 +
hw/s390x/s390-virtio-ccw.c | 1 +
hw/xen/xen-pvh-common.c | 1 +
hw/xenpv/xen_machine_pv.c | 2 +-
include/hw/i386/pc.h | 1 +
12 files changed, 14 insertions(+), 3 deletions(-)
This patch should be split per machine / area of maintenance,
so maintainers can officially Ack their commitment to security
boundary for their machine.
I'm not sure LoongArch / RISCV / PPC are. If this was previously
discussed, then pointer to the public discussions should be listed
in the patch description.
Those are explicitly documented here:
https://www.qemu.org/docs/master/system/security.html#virtualization-use-case
so this patch is just encoding what has already been defined.
I probably missed when this was accepted, we are good then!
That said, 1/ Nitro Enclave are missing and 2/ this series organization
is not easy to follow to me: I'd rather a per-machine approach, with a
'info qom-tree' output justifying the devices, then finish the series
with busses-based devices expected to be secure. I dont quite follow
this approach. I'm not asking to redo the series since it is already
reviewed.
