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

[Eric Auger]

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

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