arm64: Dealing with VHE-only CPUs

+ * @mask Mask of the features that are overriden by @val

Quoted 1 line · Marc Zyngier

+ * @mask Mask of the features that are overriden by @val

FYI, I checkpatched this by accident and it pointed out a typo ('overridden').

It also complained about a tab thing in the next patch (the last hunk has a tab followed by 8 spaces), though that was just carried over from the line before the patch.

It seems that the CPUs part of the SoC known as Apple M1 have the terrible habit of being stuck with HCR_EL2.E2H==1, in violation of the architecture.

Try and work around this deplorable state of affairs by detecting the stuck bit early and short-circuit the nVHE dance. Additional filtering code ensures that attempts at switching to nVHE from the command-line are also ignored.

It is still unknown whether there are many more such nuggets to be found...

Reported-by Hector Martin <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/kernel/head.S           | 39 +++++++++++++++++++++++++++---
 arch/arm64/kernel/hyp-stub.S       |  8 +++---
 arch/arm64/kernel/idreg-override.c | 13 +++++++++-
 3 files changed, 52 insertions(+), 8 deletions(-)

CPUs stuck in VHE mode need some additional care if the kernel is compiled without CONFIG_ARM64_VHE.

Treat this case as another version of a mismatched boot, and prevent KVM from being initialised. The machine will boot in some bizarre state, using TPIDR_EL1 instead of TPIDR_EL2, but otherwise be functional.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/include/asm/virt.h | 18 +++++++++++++-----
 arch/arm64/kvm/va_layout.c    |  9 +++++++++
 2 files changed, 22 insertions(+), 5 deletions(-)

Quoted 8 lines · Marc Zyngier

CPUs stuck in VHE mode need some additional care if the kernel is compiled without CONFIG_ARM64_VHE.

Treat this case as another version of a mismatched boot, and prevent KVM from being initialised. The machine will boot in some bizarre state, using TPIDR_EL1 instead of TPIDR_EL2, but otherwise be functional.

Quoted 5 lines

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/include/asm/virt.h | 18 +++++++++++++-----
 arch/arm64/kvm/va_layout.c    |  9 +++++++++
 2 files changed, 22 insertions(+), 5 deletions(-)

Hmm, I think we definitely need _something_ here, but it's a bit annoying to put ourselves into this weird state just for the sake of one stupid machine.

What if we dropped CONFIG_ARM64_VHE and made the VHE code unconditional instead? Is there a good reason to allow it to be disabled nowadays?

Quoted 15 lines · Will Deacon

Quoted 13 lines · Marc Zyngier

CPUs stuck in VHE mode need some additional care if the kernel is compiled without CONFIG_ARM64_VHE.

Treat this case as another version of a mismatched boot, and prevent KVM from being initialised. The machine will boot in some bizarre state, using TPIDR_EL1 instead of TPIDR_EL2, but otherwise be functional.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/include/asm/virt.h | 18 +++++++++++++-----
 arch/arm64/kvm/va_layout.c    |  9 +++++++++
 2 files changed, 22 insertions(+), 5 deletions(-)

Quoted 4 lines

Hmm, I think we definitely need _something_ here, but it's a bit annoying
to put ourselves into this weird state just for the sake of one stupid machine.

Which is why I'm not keen at all on this patch, and I'm happy to see the machine die a painful death. We really can't be blamed for terminally buggy HW, which the M1 obviously is.

Quoted 2 lines

What if we dropped CONFIG_ARM64_VHE and made the VHE code unconditional instead? Is there a good reason to allow it to be disabled nowadays?

What do we do for the other camp, aka people really wanting to run nVHE without any command line parameter? I can't see why you'd want to do that, but hey, that's only me.

I'd be quite happy to see CONFIG_ARM64_VHE go though. Let me know if you want a patch doing that instead.

Quoted 16 lines · Marc Zyngier

Quoted 15 lines · Will Deacon

Quoted 13 lines · Marc Zyngier

CPUs stuck in VHE mode need some additional care if the kernel is compiled without CONFIG_ARM64_VHE.

Treat this case as another version of a mismatched boot, and prevent KVM from being initialised. The machine will boot in some bizarre state, using TPIDR_EL1 instead of TPIDR_EL2, but otherwise be functional.

Signed-off-by Marc Zyngier <[email protected]>

---
 arch/arm64/include/asm/virt.h | 18 +++++++++++++-----
 arch/arm64/kvm/va_layout.c    |  9 +++++++++
 2 files changed, 22 insertions(+), 5 deletions(-)

Quoted 8 lines

Quoted 4 lines

Hmm, I think we definitely need _something_ here, but it's a bit annoying
to put ourselves into this weird state just for the sake of one stupid machine.

Which is why I'm not keen at all on this patch, and I'm happy to see the machine die a painful death. We really can't be blamed for terminally buggy HW, which the M1 obviously is.

Perhaps, but it's not clear at all how the problem manifests and so we _will_ be blamed when things go wonky, especially as the real culprits all seem to be hiding...

Quoted 3 lines

Quoted 2 lines

What if we dropped CONFIG_ARM64_VHE and made the VHE code unconditional instead? Is there a good reason to allow it to be disabled nowadays?

Quoted 3 lines

What do we do for the other camp, aka people really wanting to run nVHE without any command line parameter? I can't see why you'd want to do that, but hey, that's only me.

They can pass the command-line parameter, no? If we ever get CMDLINE_EXTEND support back, they could even add it in there!

Quoted 3 lines

I'd be quite happy to see CONFIG_ARM64_VHE go though. Let me know if you want a patch doing that instead.

Yes please.