On Mon, 28 Apr 2025 19:33:10 +0100,
Ganapatrao Kulkarni <gankulkarni@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Marc,
>
> I am trying nv-next branch and I believe these FGT related changes are
> merged. With this, selftest arm64/set_id_regs is failing. From initial
> debug it seems, the register access of SYS_CTR_EL0, SYS_MIDR_EL1,
> SYS_REVIDR_EL1 and SYS_AIDR_EL1 from guest_code is resulting in trap
> to EL2 (HCR_ID1,ID2 are set) and is getting forwarded back to EL1,
> since EL1 sync handler is not installed in the test code, resulting in
> hang(endless guest_exit/entry).
I don't see this problem here. At the very least, an EL1 Linux guest
runs just fine accessing these registers.
>
> It is due to function "triage_sysreg_trap" is returning true.
>
> When guest_code is in EL1 (default case) it is due to return in below if.
>
> if (tc.fgt != __NO_FGT_GROUP__ &&
> (vcpu->kvm->arch.fgu[tc.fgt] & BIT(tc.bit))) {
> kvm_inject_undefined(vcpu);
> return true;
> }
>
> IMO, Host should return the value of these sysreg read instead of
> forwarding the trap to guest or something more to be added to
> testcode?
This is not a forward. It is an UNDEF. But none of these system
registers are ever supposed to UNDEF.
So something is setting the FGU bit mapped to HFGRTR_EL2.MIDR_EL1 to
1, and forces the register to UNDEF, assuming your analysis is
correct. I'm afraid you'll have to dig a bit deeper.
M.
--
Without deviation from the norm, progress is not possible.
