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)]

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@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,

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@xxxxxxxxxxx/