Messages in this thread | | | Date | Mon, 8 Apr 2024 16:14:06 -0700 | From | Dan Williams <> | Subject | 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 |
| |
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@fujitsu.com> 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.
| |