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

From: Leif Lindholm <leif@nuviainc.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Radoslaw Biernacki" <rad@semihalf.com>,
	kvm-devel <kvm@vger.kernel.org>,
	"David Hildenbrand" <david@redhat.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"Thomas Huth" <thuth@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Halil Pasic" <pasic@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Aleksandar Rikalo" <aleksandar.rikalo@syrmia.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Greg Kurz" <groug@kaod.org>, qemu-s390x <qemu-s390x@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	qemu-ppc <qemu-ppc@nongnu.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Aurelien Jarno" <aurelien@aurel32.net>
Subject: Re: [PATCH 2/7] hw/boards: Introduce 'kvm_supported' field to MachineClass
Date: Fri, 19 Feb 2021 15:52:51 +0000	[thread overview]
Message-ID: <20210219155251.GI1664@vanye> (raw)
In-Reply-To: <CAFEAcA-A=TG43w2yNfrDwCgYYNZBEa25cM_yYgREfQyKa=PZEQ@mail.gmail.com>

On Fri, Feb 19, 2021 at 12:08:05 +0000, Peter Maydell wrote:
> 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.

Yes. This applies to sbsa-ref, for example.
We explicitly want to start in EL3, so no KVM for us.

/
    Leif

> 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