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 |
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
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
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
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 --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,
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(+)