Re: [PATCH v2] PCI/AER: Consolidate CXL, ACPI GHES and native AER reporting paths

[Jonathan Cameron <Jonathan.Cameron@huawei.com>]

On Fri, 25 Apr 2025 12:32:10 +0200
Karolina Stolarek <karolina.stolarek@oracle.com> wrote:

> On 24/04/2025 19:28, Bjorn Helgaas wrote:
> > [+to Yijun @Dell in case there's some testing opportunity, thread at
> > https://lore.kernel.org/r/81c040d54209627de2d8b150822636b415834c7f.1742900213.git.karolina.stolarek@oracle.com]
> > 
> > On Thu, Apr 24, 2025 at 11:01:11AM +0200, Karolina Stolarek wrote:  
>  >>
> >> The only way to inject GHES errors I'm aware of is Mauro's patch for
> >> qemu[1], so I went down the virtualization path. As for working with the
> >> actual hardware, I'd need to ask around and learn more about the platform.  
> > 
> > I'd be surprised if the qemu firmware supports firmware-first
> > handling, so I wouldn't expect to be able to exercise this path that
> > way.  I think there are some bits in HEST and similar tables that tell
> > us about this, e.g., ACPI r6.5, sec 18.3.2.4.  
> 
> It's possible that some of the nuances of this escaped me. I decided to 
> pick up the series, as I saw "PCI Express bus error injection via GHES" 
> script and thought it might be useful.

With Mauro's series you can inject (on ARM64 virt) any CPER record you
like.  That doesn't synchronize the wider state of the system though
so may not exercise everything (PCI registers etc not updated as it
is only injecting the record).  Mostly it just works, as remarkably 
few error handlers actually take the state of the components on which
the error is reported into account.

The aim is specifically to allow exercising FW first error handling
paths because it's a pain to get real systems that have firmware to inject
the full range of what the kernel etc need to handle.

x86 support for emulated injection is a work in progress (more of a mess wrt
to the different ways the event signaling is handled than it is on arm64).

I did have an earlier version of that work wired up to the same
hooks as the native CXL error injection but I dropped it from my QEMU
CXL staging tree for now as it was a pain to rebase whilst Mauro was rapidly
revising the infrastructure.  I'll bring it back when I get time.

Jonathan

> 
> > Unfortunately there are some typos in the spec (FIRMWARE_FIRST,
> > FIRMWAREFIRST in 18.4), so it's a little hard to find all the
> > references.  
> 
> Thanks for the pointers, I'll take a look.
> 
> > It's a long shot, but I added Yijun as a Dell contact that who might
> > have a pointer to someone who could possibly test GHES logging on a
> > Dell box with and without your patch so we could have a concrete
> > comparison of the dmesg log differences.  
> 
> Thank you very much. Let's see, maybe we'll get lucky :)
> 
> All the best,
> Karolina
> 
> >   
> >>> If you can't produce actual logs for comparison, I think we can take
> >>> info from a sample log somebody has posted and synthesize what the
> >>> changes would be after this patch.  
> >>
> >> I also found some logs at some point, mostly from 2021 and 2023, but I felt
> >> bad about mocking up the messages and tried to produce actual logs. If I
> >> can't find a way to get this working in two weeks, I'll revisit this idea.
> >>
> >> All the best,
> >> Karolina
> >>
> >> -------------------------------------------------------------
> >> [1] - https://lore.kernel.org/lkml/76824dfc6bb5dd23a9f04607a907ac4ccf7cb147.1740653898.git.mchehab+huawei@kernel.org/  
> 
>