Re: [PATCH 01/28] hw: mark secure machines for x86, s390, ppc, arm, loonarch, riscv

[Philippe Mathieu-Daudé <philmd@xxxxxxxxxxxxxxxx>]

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é <berrange@xxxxxxxxxx>
> > > ---
> > >    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.