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