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 08:13:48 -0700
Dave Jiang <dave.jiang@intel.com> wrote:

> On 4/9/25 7:13 AM, Gregory Price wrote:
> > On Mon, Apr 07, 2025 at 08:31:13AM +0000, Zhijian Li (Fujitsu) wrote:  
> >> [1] https://lore.kernel.org/linux-cxl/20240409075846.85370-1-lizhijian@fujitsu.com/  
> > 
> > After looking at this, I see why this hasn't been fixed in QEMU.
> > Basically QEMU doesn't implement the right reset mechanism.
> > 
> > ct3_reset calls
> > 	cxl_component_register_init_common()
> > 		ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_GLOBAL_CONTROL,
> > 				 HDM_DECODER_ENABLE, 0)
> > 
> > But it never resets MEM_ENABLE in the dvsecs.
> > 
> > I'm not sure it's sane for Linux to be trying to handle hardware that
> > doesn't itself reset correctly - and doing this fix just for QEMU seems
> > a bit too far.  
> 
> I agree. No need to twist Linux in a bunch for something broken on QEMU. Until there's actual hardware that does this deployed in the field, we should just leave the Linux driver as is.

It's not yet fixed in QEMU because the proposed fix stops the CDAT DOE working.
https://lore.kernel.org/linux-cxl/20240802174010.000025e7@Huawei.com/

We don't correctly handle reset today.  I'm thoroughly in favour
of fixing qemu, but we need to do it carefully and not break other.

> 
> > 
> > The correct fix here is building an accessor for the existing CXL dvsecs
> > and updating it during ct3_reset.

Yes. Will be something along those lines but needs thorough testing.

Jonathan

> > 
> > ~Gregory  
> 
>