On Fri, 19 Feb 2021 at 11:58, Daniel P. Berrangé <berrange@xxxxxxxxxx> 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
