[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/7] hw/boards: Introduce 'kvm_supported' field to MachineCla
Re: [PATCH 2/7] hw/boards: Introduce 'kvm_supported' field to MachineClass
Fri, 19 Feb 2021 15:52:51 +0000
On Fri, Feb 19, 2021 at 12:08:05 +0000, Peter Maydell wrote:
> On Fri, 19 Feb 2021 at 11:58, Daniel P. Berrangé <email@example.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
> 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.
> 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).
> -- PMM
- [PATCH 0/7] hw/kvm: Exit gracefully when KVM is not supported, Philippe Mathieu-Daudé, 2021/02/19
- [PATCH 3/7] hw/arm: Set kvm_supported for KVM-compatible machines, Philippe Mathieu-Daudé, 2021/02/19
- [PATCH 4/7] hw/mips: Set kvm_supported for KVM-compatible machines, Philippe Mathieu-Daudé, 2021/02/19
- [RFC PATCH 5/7] hw/ppc: Set kvm_supported for KVM-compatible machines, Philippe Mathieu-Daudé, 2021/02/19
- [PATCH 6/7] hw/s390x: Set kvm_supported to s390-ccw-virtio machines, Philippe Mathieu-Daudé, 2021/02/19
- [PATCH 7/7] accel/kvm: Exit gracefully when KVM is not supported, Philippe Mathieu-Daudé, 2021/02/19
- Re: [PATCH 0/7] hw/kvm: Exit gracefully when KVM is not supported, Peter Maydell, 2021/02/19
- Re: [PATCH 0/7] hw/kvm: Exit gracefully when KVM is not supported, Daniel P . Berrangé, 2021/02/19