Re: [RFC PATCH v1 01/01] PCIe DOE for PCIe and CXL 2.0

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

...

> 
> >   
> >>   
> >>>> 
> >>>> Just like you we feel what's most important is to have DOE supported so that
> >>>> UEFI and Linux kernel and drivers can progress.  We're also contributing to
> >>>> writing compliance tests for the CXL Compliance Software Development WG.    
> >>> 
> >>> Great.    
> >> 
> >> Is anyone doing the kernel enabling for it?  
> > 
> > Planning to look at this but plenty of other things on my todo list if someone
> > else gets to it first.
> > 
> > Generic DOE support should be straight forward (the infrastructure).
> > Parsing CDAT also straight forward.
> > Doing something with the results is hard unless we just provide an interface for
> > userspace to query them for a given device - or dump the table
> > (I think we do want to be able to that). 
> > 
> > What I'm really not sure on is how to handle NUMA domains that are created late
> > in the kernel boot sequence.  The  ACPI flow is set up with the assumption
> > that we can get them from SRAT very early in boot. Need to figure out how to
> > work around that. (e.g. preallocate a bunch of spare nodes for example though that's
> > ugly).  Note IIRC the kernel doesn't do runtime update of any of the ACPI
> > performance parameters yet (_SLI, _HMA) so there probably isn't any infrastructure
> > that we can reuse.
> > 
> > There is also the firmware based enumeration and description option (OS not necessarily
> > aware of CXL) in which this is all up to EDK2 and the kernel gets it all presented
> > as standard tables.  
> 
> Do we know who’s on this as part of the EDK2 development?  It would be great if they could
> address the SRAT/HMAT generation from reading CDAT.  EDK2 does address CXL 1.1 now.

No idea who, if anyone, is looking at this currently.  Perhaps ask on the EDK2 list?

Jonathan

> 
> > 
> > As you can perhaps tell from my half done reviews, this week disappeared in
> > other things so bit of catch up for me to do next week.
> > 
> > Thanks,
> > 
> > Joanthan
> > 
...