Re: [PATCH 2/7] hw/boards: Introduce 'kvm_supported' field to MachineClass

[Peter Maydell]

On Fri, 19 Feb 2021 at 11:58, Daniel P. Berrangé <berrange@redhat.com> wrote:
> Is the behaviour reported really related to KVM specifically, as opposed
> to all hardware based virt backends ?
>
> eg is it actually a case of some machine types being  "tcg_only" ?

Interesting question. At least for Arm the major items are:
 * does the accelerator support emulation of EL3/TrustZone?
   (KVM doesn't; this is the proximate cause of the assertion
   failure if you try to enable KVM for the raspi boards.)
 * does the board type require a particular CPU type which
   KVM doesn't/can't support?
Non-KVM accelerators could at least in theory have different answers
to those questions, though in practice I think they do not.

I think my take is that we probably should mark the boards
as 'tcg-only' vs 'not-tcg-only', because in practice that's
the interesting distinction. Specifically, our security policy
https://qemu.readthedocs.io/en/latest/system/security.html
draws a boundary between "virtualization use case" and
"emulated", so it's really helpful to be able to say clearly
"this board model does not support virtualization, and therefore
any bugs in it or its devices are simply outside the realm of
being security issues" when doing analysis of the codebase or
when writing or reviewing new code.

If we ever have support for some new accelerator type where there's
a board type distinction between KVM and that new accelerator and
it makes sense to try to say "this board is supported by the new
thing even though it won't work with KVM", the folks interested in
adding that new accelerator will have the motivation to look
into exactly which boards they want to enable support for and
can add a funky_accelerator_supported flag or whatever at that time.

Summary: we should name this machine class field
"virtualization_supported" and check it in all the virtualization
accelerators (kvm, hvf, whpx, xen).

thanks
-- PMM