Paolo Bonzini <[email protected]> writes: > On Wed, Mar 11, 2026 at 6:03 PM Peter Maydell <[email protected]> > wrote: >> >> On Wed, 11 Mar 2026 at 09:54, Alyssa Ross <[email protected]> wrote: >> > >> > If I create a machine with more CPUs than KVM supports, but specify >> > multiple accelerator options, QEMU will fall back to the next >> > accelerator. This is great, because if I've explicitly specified >> > multiple accelerators, I've told QEMU I'm fine with any of them being >> > used to provide the machine I want. >> > >> > When I create a machine with nested virtualization enabled, though, >> > this doesn't happen. KVM often doesn't support it, but TCG always >> > does. The nice thing to do would be for QEMU to fall back to TCG if >> > KVM can't provide, like it does when too many CPUs are requested. >> > This patch adjusts the behaviour to do that. >> > >> > This is very helpful for OS development scripts that run an OS in QEMU >> > — I want everybody to be able to run the script, always with >> > virtualization enabled because the OS requires it, but for it to take >> > advantage of KVM acceleration when available. >> > >> > Signed-off-by: Alyssa Ross <[email protected]> >> > --- >> > hw/arm/virt.c | 6 ------ >> > target/arm/kvm.c | 8 ++++++++ >> > 2 files changed, 8 insertions(+), 6 deletions(-) >> > >> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c >> > index 7456614d05..0b63b2eac3 100644 >> > --- a/hw/arm/virt.c >> > +++ b/hw/arm/virt.c >> > @@ -2372,12 +2372,6 @@ static void machvirt_init(MachineState *machine) >> > exit(1); >> > } >> > >> > - if (vms->virt && kvm_enabled() && !kvm_arm_el2_supported()) { >> > - error_report("mach-virt: host kernel KVM does not support >> > providing " >> > - "Virtualization extensions to the guest CPU"); >> > - exit(1); >> > - } >> > - >> > if (vms->virt && !kvm_enabled() && !tcg_enabled() && >> > !qtest_enabled()) { >> > error_report("mach-virt: %s does not support providing " >> > "Virtualization extensions to the guest CPU", >> >> I think there is a bigger problem here. The code in the virt >> board init assumes that the accelerator has already been >> selected: based on whether kvm_enabled() or tcg_enabled() >> it decides things like which GIC version can be used, whether >> "-machine gic-version=host" is valid or not, and so on. >> >> This bit we're deleting here is just one of multiple checks >> we do that assume that we know the accelerator already. If >> we actually don't know if we're going to be using TCG or KVM >> then all this code needs to be rethought. > > We do. This code runs at the very end of qemu_init() > (qmp_x_init_preconfig->qemu_init_board->machine_run_board_init). > > The bug is on the KVM side, as it lets the configuration slip even > though it's not valid; the above KVM check should really be more of an > abort() if anything. (This is also why I picked it despite it touching > hw/arm/virt.c - from my point of view the KVM fix made the above code > go dead).
Yeah, the problem isn't that we don't know which accelerator is in use in the virt board — we do. It's that by that point it's too late to fall back to the next acceptable accelerator if KVM can't provide nested virtualization, so we need to check earlier.
signature.asc
Description: PGP signature
