Re: [Problem ?] cxl list show nothing after reboot Re: [PATCH v2] cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window

[Dan Williams]

Zhijian Li (Fujitsu) wrote:
> 
> 
> On 06/04/2024 00:57, Jonathan Cameron wrote:
> > On Tue, 26 Mar 2024 08:26:21 +0000
> > "Zhijian Li (Fujitsu)" <lizhijian@xxxxxxxxxxx> wrote:
> > 
> >> All guys,
> >>
> >> In order to make the CXL memdev work again, i have to modify the QEMU side
> >> where it resets the "DVSEC CXL Control" during reboot. A draft changes is as below:
> >>
> >> Per 8.1.3.2 DVSEC CXL Control (Offset 0Ch), Default value of BIT(2) is 0. So is it reasonable
> >> to have a reset dvsecs in QEMU during reboot?
> >>
> >> Any comments @Janathan
> > 
> > Hi,
> > 
> > Sorry it took me so long to get to this.
> > 
> > What are you attempting to do? Use an OS reboot on QEMU to check that the flows
> > meant for BIOS configuration work - 
> 
> 
> There is no doubt that *the OS rebuilds the state correctly* is the OS's responsibility.
> Providing the consistent device state is the *Device*'s responsibility.
> 
> So on reboot, the device should have a consistent device state with a fresh boot.
> My changes intended to let *Device* emulated by QEMU provide a consistent
> device state.

Why? Typically the QEMU CXL enabling is for basic checkout not for
real-world fidelity. If QEMU reboots do not result in restoring the same
device configuration as a re-launching QEMU, why is that worth fixing?
Just document it as a quirk. Now, if it is a simple fix, great, but it
seems low priority given the enabling is really only useful for kernel
development and relaunching QEMU is expected.