[PATCH] arm64/acpi: Add fixup for HPE m400 quirks

[msalter@redhat.com (Mark Salter)]

On Thu, 2018-06-28 at 11:06 +0100, James Morse wrote:
> Hi Mark,
> 
> On 26/06/18 21:20, Mark Salter wrote:
> > On Tue, 2018-06-26 at 15:51 +0100, James Morse wrote:
> > > On 25/06/18 16:34, Mark Salter wrote:
> > > > On Fri, 2018-06-22 at 11:19 -0400, Mark Salter wrote:
> > > > > I'm going to hack something to get to the ghes info earlier in boot and
> > > > > check the things you mention above wrt Error Status Block and GHES.0.
> > > > 
> > > > So I had to end up instrumenting the EFI stub to see where the error came
> > > > from. At the start of the stub, there is no GHES.2 error. The error first
> > > > shows up after the stub's call to ExitBootServices returns.
> > > 
> > > What's the notification type of GHES.2? I'm guessing POLLed or some kind of IRQ.
> > > These systems don't have EL3, so the CPU must continue running while something
> > > external generates the CPER records. The records being visible is the last point
> > > the faulty-access could have been made, with the window of time depending on how
> > > fast this external-thing receives and processes the error.
> > 
> > There's a System Control Processor (slimpro) on the SoC which can interact with
> > the CPU in various ways and which has access to memory and other hw.
> 
> Thanks, saves me guessing!
> 
> 
> > > > So it looks
> > > > like the firmware itself is causing the error. There's still a chance that
> > > > the stub is doing something wrong with the memory map passed to the
> > > > firmware, so I'll try to eliminate that as well.
> > > 
> > > adding delay loops will help prove the EFIStub is innocent.
> > 
> > Didn't change anything.
> 

Just closing the loop on this...

> Okay, so just to clarify, a delay before ExitBootServices doesn't cause the
> error to show up before ExitBootServices, so the error hasn't occurred prior to
> this point.

Correct. I have never seen the error before ExitBootServices.

> And a delay after ExitBootServices allows us to see the error before we exit
> into head.S. (this rules out a bug in head.S)
> The delays should be long enough to tell us this slimpro isn't generating the
> error records N seconds after reset.

No delay needed after ExitBootServices. The error would be there right after the
call returns back to stub.


> 
> Given this I agree we should disable_hest based on the DMI platform name and the
> UEFI version number. (it may be earlier firmware didn't have this bug).
> 
> 
> I don't have anything to test this on, so I've picked the DMI strings out the
> demsg output on that bugzilla entry. Any chance you could give it a test?
> 
> 
> > > Are redhat able to rebuild UEFI on these systems? (Can it be fixed?)
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1285107 is about the m400
> > > description of the GIC, comments 15 and 16 show a UEFI patch to something other
> > > than the upstream platforms tree[0], and new firmware being tested.
> > > (although this may be wishful thinking)
> > 
> > HPe would respond to bug reports until m400 reached EOL. They have been pretty
> > clear that no more firmware updates will be done.
> 
> Thanks, it was a bit murky from that ticket...
> 
> 
> Thanks for doing this!
> 
> James