Messages in this thread | | | From | "Zhijian Li (Fujitsu)" <> | 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 | Date | Tue, 9 Apr 2024 06:53:38 +0000 |
| |
On 09/04/2024 07:14, Dan Williams wrote: > 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,
It was confirmed to be true in current QEMU, so we should fix the QEMU[1].
> why is that worth fixing?> Just document it as a quirk. Now, if it is a simple fix, great, but i> seems low priority given the enabling is really only useful for kernel > development and relaunching QEMU is expected.
Personally, QEMU deserves a better solution than relaunching.
[1] https://lore.kernel.org/all/20240402014647.3733839-2-lizhijian@fujitsu.com/
| |