linux-kernel - 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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 9 Apr 2024 06:53:38 +0000
From: "Zhijian Li (Fujitsu)" <lizhijian@...itsu.com>
To: Dan Williams <dan.j.williams@...el.com>, Jonathan Cameron
	<Jonathan.Cameron@...wei.com>
CC: Robert Richter <rrichter@....com>, Davidlohr Bueso <dave@...olabs.net>,
	Dave Jiang <dave.jiang@...el.com>, Alison Schofield
	<alison.schofield@...el.com>, Vishal Verma <vishal.l.verma@...el.com>, Ira
 Weiny <ira.weiny@...el.com>, "linux-cxl@...r.kernel.org"
	<linux-cxl@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Xingtao Yao (Fujitsu)"
	<yaoxt.fnst@...itsu.com>
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



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@...itsu.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/