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