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

> Paolo, can you unqueue this for a bit while we think about it?

Yes, of course.

Paolo


Reply via email to