Re: Some thoughts and questions about CXL & MCE

[Dan Williams <dan.j.williams@intel.com>]

Jonathan Cameron wrote:
[..]
> One other wrinkle I'm working through is the control of CPER vs normal reporting.
> Current thought is we do what ACPI allows and start in firmware first, until the
> _OSC call.  If that requests native handling we go back to what we currently
> support (native only emulation).
> 
> However, there isn't a convenient way to mess with what Linux asks for which we'd
> want to make it easy to test the handling once the driver stack is up.
> 
> I'm not sure anyone would be keen on a pci_aer=no-ask,cxl-mem-error=no-ask type
> kernel boot parameter to instruct the kernel to never ask for control.

I just expressed a similar lament to someone else asking about this, and
claimed that is up to the BIOS to say "no", not for Linux to skip
asking. It turns out that the Linux pci=noear knob predated _OSC:

   7ece14175376 PCI/AER: Remove aerdriver.forceload kernel parameter

..., so there was legacy to carry forward. Otherwise, in a post _OSC
world it's the OS responsibility to ask and the firmware responsibility
to optionally say, "no".

> I also don't much like a qemu parameter which basically says 'report aer as
> broken so the OS can't grab it'. Anyhow those are details.
> 
> Ah well. Getting the _OSC handshake to save what was negotiated on qemu side was
> fiddly but I got that working on Friday so I have all the pieces for protocol errors
> done (ARM only for now - I need to look at notifications in ACPI on x86 + enable
> HEST in general on qemu-x86).  Will post an RFC for ARM shortly.
> 
> Bare metal will be burried in bios config most likely.
> 
> Jonathan
> 
> 
> > 
> > > I don't fully understand the CXL spec yet (it's difficult for me), so 
> > > the above ideas may be immature, but I really want to figure out how we 
> > > can make CXL & MCE work.  I'd really appreciate it if you could help me 
> > > on this!
> > > 
> > > [1] 
> > > https://lore.kernel.org/linux-cxl/20231220-cxl-cper-v5-0-1bb8a4ca2c7a@intel.com/T/#u  
> > 
> > Following this work from Smita and Ira is the right path.
>