Hi Alyssa, On 6/17/25 4:17 PM, Alyssa Ross 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 -machine virtualization=on, 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.
Hum I think I misundertood your point. I guess you meant you get "qemu-system-aarch64: mach-virt: KVM does not support providing Virtualization extensions to the guest CPU" which sounds the usual behavior of qemu in case we attempt to run a feature on a host that does not support it. > > 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. Switching to another accel mode is a policy that is not implemented by qemu. There is no such situation where qemu would switch from kvm accel mode to TCG. You need to implement this policy in your test env I think Thanks Eric
