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