Re: [RFC PATCH] cxl/core: reenable Mem_Enable bit of DVSEC control when RR decodes outside platform ranges

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

On Wed, 9 Apr 2025 09:01:45 -0500
Gregory Price <gourry@gourry.net> wrote:

> On Wed, Apr 09, 2025 at 03:48:42AM +0000, Ye, Huaisheng wrote:
> > From: Gregory Price <gourry@gourry.net>
> > The phenomenon I observed here is that the content of RR is incorrect, as it is not within the hpa_range of the root decoder.
> > Here are the debug messages of dmesg from site scene. FYI.
> > 
> >  [    7.683508] cxl_dvsec_rr_decode: cap = 0x1e
> >  [    7.683535] cxl_dvsec_rr_decode: ctrl = 0x6		<-- which means CXL_DVSEC_MEM_ENABLE has been set by firmware (Qemu)
> >  [    7.683557] cxl_dvsec_rr_decode: range0 base = 0, size = 2147483648   <- endpoint's dvsec_range
> > 
> >  [    7.761781] dvsec_range_allowed: cxld->hpa_range.start = 11005853696  <- root decoder
> >  [    7.761782] dvsec_range_allowed: cxld->hpa_range.end   = 45365592063  
> 
> Are you interleaving like 16 2GB devices?  Because the RR here has 2GB
> of capacity, while the root describes 32GB of capacity.  Just trying to
> make sense of the configuration here.  If you can share your qemu
> config, tha would be helpful.
> 
> > I agree Qemu should fix this issue, it occurs probabilistically.  
> 
> Hm, Jonathan is it unreasonable to go off an clear the ctrl bits in
> ct3_reset?  I'm not sure what the warm-reset procedure is, but it does
> seem like we shouldn't cache decoder / ctrl bit programmings across
> reset.  Not sure if just re-calling build_dvsecs is sufficient.

We need to handle the difference between a warm-reset and a cold one correctly
I think + CXL reset ideally.  This particular thing was never a priority
for me but I'm more than happy to review patches from others.

If not I'll get to it eventually, but I suspect there is a bunch more to do than
just this and the build_dvsecs() in ct3d_reset was the thing that
broken the DOE last time.

Testing wise it needs someone to check the entire device configuration and
ensure the correct things have been reset.

Oh and on top of that move to the newer reset handling in qemu probably
docs/devel/reset.rst 

Jonathan



> 
> > And I think this patch would help CXL driver to dealing with various firmware situations.  
> 
> The question is whether this behavior is even feasible on real hardware.
> The issue seems to basically be that QEMU doesn't implement the right
> reset mechanism, because other
> 
> ~Gregory