Hi Miguel, Marc, On 5/27/25 2:54 PM, Miguel Luis wrote: > >> On 27 May 2025, at 12:01, Marc Zyngier <m...@kernel.org> wrote: >> >> On Tue, 27 May 2025 12:33:23 +0100, >> Miguel Luis <miguel.l...@oracle.com> wrote: >>> Hi Eric, >>> >>>> On 27 May 2025, at 06:24, Eric Auger <eric.au...@redhat.com> wrote: >>>> >>>> Now that ARM nested virt has landed in kvm/next, let's turn the series >>>> into a PATCH series. The linux header update was made against kvm/next. >>>> >>>> For gaining virt functionality in KVM accelerated L1, The host needs to >>>> be booted with "kvm-arm.mode=nested" option and qemu needs to be invoked >>>> with: -machine virt,virtualization=on. >>> For the current kvmarm/next the guest also needs >>> “kvm-arm.mode=nested” I believe. >> No, unless you want the guest itself to be NV-capable. Effectively you don't need "kvm-arm.mode=nested" except if you want want multiple level of nesting. >> > Correct, I got carried away with some mode combinations. Maybe we should > depict > here more broadly how NV might be used with different mode combinations. I'll > think about this further ahead. > > As far this series go I couldn't found any issue booting a L1 guest with > virtualization=on and a L2 guest with virtualization=off.
on my end I tested with various untouched L2 guests (debian, fed, rhel) in 4kB/4kB/4KB page size mode (host, L1, L2). Those configs were successful. with 64kB/64kB/64kB configs I am less lucky atm. One one machine I cannot boot L1 with virtualization=on. On the other I can boot L1 but cannot boot L2. Trying my best to debug a little bit further with my setup. Anyway if somebody else can try 64kB configs, it would help to confirm whether there are pending issues. I don't think they are related to this qemu integration series though. Thanks Eric > > Miguel > >> M. >> >> -- >> Without deviation from the norm, progress is not possible. >
