Hi Eric,
> On 19 Jun 2025, at 13:29, Eric Auger <eric.au...@redhat.com> wrote:
>
> Hi,
>
> On 6/17/25 5:50 PM, Miguel Luis wrote:
>> Hi Eric,
>>
>>> On 17 Jun 2025, at 15:41, Eric Auger <eric.au...@redhat.com> wrote:
>>>
>>>
>>>
>>> On 6/17/25 5:23 PM, Miguel Luis wrote:
>>>> Hi Alyssa,
>>>>
>>>>> On 17 Jun 2025, at 14:17, Alyssa Ross <h...@alyssa.is> wrote:
>>>>>
>>>>> Eric Auger <eric.au...@redhat.com> writes:
>>>>>
>>>>>> From: Haibo Xu <haibo...@linaro.org>
>>>>>>
>>>>>> Up to now virt support on guest has been only supported with TCG.
>>>>>> Now it becomes feasible to use it with KVM acceleration.
>>>>>>
>>>>>> Also check only in-kernel GICv3 is used along with KVM EL2.
>>>>>>
>>>>>> Signed-off-by: Haibo Xu <haibo...@linaro.org>
>>>>>> Signed-off-by: Miguel Luis <miguel.l...@oracle.com>
>>>>>> Signed-off-by: Eric Auger <eric.au...@redhat.com>
>>>>>> Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
>>>>> Hi! From what I can tell, this will produce an error on hosts that
>>>>> don't support nested virtualization when QEMU is invoked with -accel
>>>>> kvm:tcg
>>>> I didn’t know '-acell kvm:tcg’ could be used as a fallback mechanism
>>>> between
>>>> acceleration modes. May I ask whether do you manage the ‘-cpu’ type for
>>>> ‘-accel
>>>> kvm:tcg’ with cpu ‘max’ ?
>>> Does it exist?
>>> qemu-system-aarch64: -accel kvm:tcg: invalid accelerator kvm:tcg
>> Maybe Alyssa is referring to ‘-M
>> virt,accel=kvm:tcg,virtualization=on,gic-version=3’ ?
>>
>> The above didn’t triggered any error. Anyhow if the above does what Alyssa’s
>> saying
>> we would just be missing the check for || !tcg_enabled() in this patch, I
>> believe.
>
> After discussion with Paolo, the lack of the CAP should be detected
> earlier in kvm_init/kvm_arch_init to allow the fallback to TCG.
> in target/arm/kvm.c kvm_arch_init() some generic caps are checked but
> none of them are related to machine settings and this code is virt arm
> machine agnostic.
>
> I checked and adding
>
> if (object_dynamic_cast(OBJECT(ms), TYPE_VIRT_MACHINE)) {
> VirtMachineState *vms = VIRT_MACHINE(ms);
>
> if (vms->virt && !kvm_arm_el2_supported()) {
> error_report("KVM does not support nested virtualization");
> ret = -EINVAL;
> }
> }
>
> at the end of the function would do the job. But as I said previously
> this is not done for other virt arm machine options that are accel
> specific or require special KVM caps (secure, mte for instance) so it
> would be a change in the approach.
>
Got it.
> As pointed out before fallback spirit was rather: "KVM isn't enabled"
> than for "KVM doesn't support a specific feature".
>
Thank you for getting to the bottom of it.
Miguel
> Thanks
>
> Eric
>
>
>
>
> it's purely the first accelerator that says it can work
> 1:03
> <https://redhat-internal.slack.com/archives/C04KFKV2SE9/p1750331005242709>
> pbonzini
> Where "can work" is only based on the host.
>
>
>>
>> Miguel
>>
>>> Alyssa, didn't you mean -accel kvm or --accel tcg
>>>> But more importantly, is this what you’re referring to?
>>>>
>>>> Although,
>>>>
>>>>> -machine virtualization=on,
>>>> should work for both '-accel kvm’ and ‘-accel tcg’.
>>>>
>>>>> but I don't think that's the ideal
>>>>> behaviour. It would make more sense for it to fall back to the first
>>>>> permitted accel option that does support running the machine as
>>>>> configured, so if hardware nested virtualization is not supported, it
>>>>> should fall back to TCG.
>>>>>
>>>>> I maintain an OS development environment that includes scripts for
>>>>> running images in QEMU, where running KVM on those images is a
>>>>> requirement. Currently, those scripts simply force TCG on aarch64.
>>>>> With this change, to take advantage of KVM NV support, I'd have to try
>>>>> to identify in the script whether NV would be supported. QEMU would be
>>>>> in a much better position to determine this and fall back to TCG if it's
>>>>> unsupported, like how the -accel option with multiple values usually
>>>>> works.
>>>> Thanks,
>>>> Miguel
