Hey Eric, On Mon, 05 Jun 2023 12:28:12 +0100, Eric Auger <eauger@xxxxxxxxxx> wrote: > > Hi Marc, > > On 5/15/23 19:30, Marc Zyngier wrote: > > This is the 4th drop of NV support on arm64 for this year. > > > > For the previous episodes, see [1]. > > > > What's changed: > > > > - New framework to track system register traps that are reinjected in > > guest EL2. It is expected to replace the discrete handling we have > > enjoyed so far, which didn't scale at all. This has already fixed a > > number of bugs that were hidden (a bunch of traps were never > > forwarded...). Still a work in progress, but this is going in the > > right direction. > > > > - Allow the L1 hypervisor to have a S2 that has an input larger than > > the L0 IPA space. This fixes a number of subtle issues, depending on > > how the initial guest was created. > > > > - Consequently, the patch series has gone longer again. Boo. But > > hopefully some of it is easier to review... > > > > [1] https://lore.kernel.org/r/20230405154008.3552854-1-maz@xxxxxxxxxx > > > > Andre Przywara (1): > > KVM: arm64: nv: vgic: Allow userland to set VGIC maintenance IRQ > > I guess you have executed kselftests on L1 guests. Have all the tests > passed there? On my end it stalls in the KVM_RUN. No, I hardly run any kselftest, because they are just not designed to run at EL2 at all. There's some work to be done there, but I just don't have the bandwidth for that (hint, wink...) > > for instance > tools/testing/selftests/kvm/aarch64/aarch32_id_regs.c fails in > test_guest_raz(vcpu) on the KVM_RUN. Even with a basic > > static void guest_main(void) > { > GUEST_DONE(); > } My guess is that the test harness expects things to run at EL1. Depending on the value you get for HCR_EL2, you could get all sort of odd behaviours. Also, the harness configures EL1 only, which is unlikely to work at EL2. My conclusion is that "processor.c" needs to be taught about EL2, at the very least. > > I get > aarch32_id_regs-768 [002] ..... 410.544665: kvm_exit: IRQ: > HSR_EC: 0x0000 (UNKNOWN), PC: 0x0000000000401ec4 > aarch32_id_regs-768 [002] d.... 410.544666: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-768 [002] ..... 410.544675: kvm_exit: IRQ: > HSR_EC: 0x0000 (UNKNOWN), PC: 0x0000000000401ec4 > aarch32_id_regs-768 [002] d.... 410.544676: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-768 [002] ..... 410.544685: kvm_exit: IRQ: > HSR_EC: 0x0000 (UNKNOWN), PC: 0x0000000000401ec4 > > looping forever instead of > > aarch32_id_regs-1085576 [079] d..1. 1401295.068739: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] ...1. 1401295.068745: kvm_exit: TRAP: > HSR_EC: 0x0020 (IABT_LOW), PC: 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] d..1. 1401295.068790: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] ...1. 1401295.068792: kvm_exit: TRAP: > HSR_EC: 0x0020 (IABT_LOW), PC: 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] d..1. 1401295.068794: kvm_entry: PC: > 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] ...1. 1401295.068795: kvm_exit: TRAP: > HSR_EC: 0x0020 (IABT_LOW), PC: 0x0000000000401ec4 > aarch32_id_regs-1085576 [079] d..1. 1401295.068797: kvm_entry: PC: > 0x0000000000401ec4 > ../.. > > Any idea or any known restriction wrt kselftests? See above. I'd love someone to actually start looking into it and devise a testing harness that would run both at EL{0,1,2} *at the same time* so that we can start exercising some of the trap behaviours that the architecture mandates. Also, Alexandru had a some KUT tests a few years ago, but I don't know what happened of them. Thanks, M. -- Without deviation from the norm, progress is not possible.
