Hi Marc, On 6/6/23 09:30, Marc Zyngier wrote: > 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...) oh OK, I missed that point. If nobody is working on this I can start looking at it. Would be interesting to run them on nested guest too. > >> >> 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. Yeah I remember that one too. Alexandru, do you have plans to revive it? That would be also interesting to run kuts on nested, giving a chance to have incremental and more unitary testing. Thanks! Eric > > Thanks, > > M. >
