[PATCH v10 00/59] KVM: arm64: ARMv8.3/8.4 Nested Virtualization support

[Marc Zyngier]

Hey Eric,

On Mon, 05 Jun 2023 12:28:12 +0100,
Eric Auger <eauger at redhat.com> 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@kernel.org
> > 
> > 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.