diff mbox series

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

Message ID 20210219114428.1936109-3-philmd@redhat.com (mailing list archive)
State New, archived
Headers show
Series hw/kvm: Exit gracefully when KVM is not supported | expand

Commit Message

Philippe Mathieu-Daudé Feb. 19, 2021, 11:44 a.m. UTC
Introduce the 'kvm_supported' field to express whether
a machine supports KVM acceleration or not.

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 include/hw/boards.h | 3 +++
 1 file changed, 3 insertions(+)

Comments

Daniel P. Berrangé Feb. 19, 2021, 11:57 a.m. UTC | #1
On Fri, Feb 19, 2021 at 12:44:23PM +0100, Philippe Mathieu-Daudé wrote:
> Introduce the 'kvm_supported' field to express whether
> a machine supports KVM acceleration or not.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  include/hw/boards.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 68d3d10f6b0..0959aa743ee 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -129,6 +129,8 @@ typedef struct {
>   *    Return the type of KVM corresponding to the kvm-type string option or
>   *    computed based on other criteria such as the host kernel capabilities
>   *    (which can't be negative), or -1 on error.
> + * @kvm_supported:
> + *    true if '-enable-kvm' option is supported and false otherwise.

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" ?



Regards,
Daniel
Peter Maydell Feb. 19, 2021, 12:08 p.m. UTC | #2
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
Daniel P. Berrangé Feb. 19, 2021, 12:10 p.m. UTC | #3
On Fri, Feb 19, 2021 at 12:08:05PM +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.

Oh, yes, that is useful to correlate with.

> 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).

Agreed.

Regards,
Daniel
Leif Lindholm Feb. 19, 2021, 3:52 p.m. UTC | #4
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
diff mbox series

Patch

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 68d3d10f6b0..0959aa743ee 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -129,6 +129,8 @@  typedef struct {
  *    Return the type of KVM corresponding to the kvm-type string option or
  *    computed based on other criteria such as the host kernel capabilities
  *    (which can't be negative), or -1 on error.
+ * @kvm_supported:
+ *    true if '-enable-kvm' option is supported and false otherwise.
  * @numa_mem_supported:
  *    true if '--numa node.mem' option is supported and false otherwise
  * @smp_parse:
@@ -209,6 +211,7 @@  struct MachineClass {
     bool nvdimm_supported;
     bool numa_mem_supported;
     bool auto_enable_numa;
+    bool kvm_supported;
     const char *default_ram_id;
 
     HotplugHandler *(*get_hotplug_handler)(MachineState *machine,