Re: Some thoughts and questions about CXL & MCE

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

Jonathan Cameron wrote:
> On Mon, 8 Jan 2024 13:14:06 -0800
> Dan Williams <dan.j.williams@intel.com> wrote:
> 
> > 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".
> 
> PCI Firmware specification rev 3.3 Section 4.5.1.
> (right at the end of page 48)
> 
> "System firmware must only mask a Control Field bit to zero if it has explicit
> knowledge that the feature will not work properly under native operating system
> control, due to platform errata or other incompatibilities."

Feel like "other incompatibilities" is the catch-all gray area for
firmware to force firmware-first operation when that ensures
"compatibility" with some 3rd party expectation.

> 
> Meh, I guess I could add a 'native-aer=broken' parameter to the qemu boot -
> I'm sure that will sail through reviews :)

Kidding aside it still feels like a bunch of work to emulate a flow in
QEMU for a firmware no one is going to run outside of kernel development
testing.  I.e. the QEMU CXL emulation is for testing the Linux kernel
not the Tianocore implementation.