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

[Gregory Price <gourry@gourry.net>]

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.

> 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