Re: [PATCH] target/arm/kvm: fall back if nested unsupported

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 3403 bytes --]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On Wed, Mar 11, 2026 at 6:03 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Wed, 11 Mar 2026 at 09:54, Alyssa Ross <hi@alyssa.is> 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 <hi@alyssa.is>
>> > ---
>> >  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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]