[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <eb28ffda-d6ee-4379-9d71-b67e9f80a58c@fujitsu.com>
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/
Powered by blists - more mailing lists