Re: [PATCH 3/5] arm64: mops: Document booting requirement for HCR_EL2.MCE2

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Oct 02, 2024 at 02:31:47PM +0100, Kristina Martsenko wrote:
> On 02/10/2024 11:38, Catalin Marinas wrote:
> > On Mon, Sep 30, 2024 at 05:10:49PM +0100, Kristina Martsenko wrote:
> >> diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst
> >> index b57776a68f15..db46af5b9f0f 100644
> >> --- a/Documentation/arch/arm64/booting.rst
> >> +++ b/Documentation/arch/arm64/booting.rst
> >> @@ -385,6 +385,9 @@ Before jumping into the kernel, the following conditions must be met:
> >>  
> >>      - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1.
> >>  
> >> +    - HCRX_EL2.MCE2 (bit 10) must be initialised to 0b1. The exception
> >> +      handler must set PSTATE.SS to 0b0.
> > 
> > That's a booting document, do we need to specify the single-step
> > exception?
> 
> A hypervisor can't just set MCE2 at kernel boot without also implementing an
> exception handler for MOPS exceptions. The handler needs to implement the
> algorithm from the Arm ARM, and in addition the kernel needs it to also clear
> SS so that breakpoints/watchpoints (and KGDB single stepping) work as expected.
> Is there a better place to specify this?

Not sure, maybe a short mops.rst document describing the exception
handling needs for a hypervisor running Linux (well, if it's just a couple
of sentences, we might as well keep them in booting.rst). In a mops.rst
you could add more lines explaining the exception handling and the
reasoning behind PSTATE.SS. In booting.rst you can just refer mops.rst.

I'm trying to remember the discussions that lead to such requirement.
Basically the worry is that the vCPU the kernel is running on migrates
to another physical CPU with a different MOPS implementation and
triggers a fault into the kernel. The kernel may not be able to handle
the fault itself, hence setting MCE2 to force trapping to EL2.

This is all fine but the requirement for the hypervisor to clear
PSTATE.SS feels a bit strange. Doesn't it break the kernel's state
machine (or gdb's) if, suddenly, it no longer traps the next
instruction?

-- 
Catalin