[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66147a3e5c55f_2583ad29433@dwillia2-xfh.jf.intel.com.notmuch>
Date: Mon, 8 Apr 2024 16:14:06 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: "Zhijian Li (Fujitsu)" <lizhijian@...itsu.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>, Dan Williams <dan.j.williams@...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
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, 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.
Powered by blists - more mailing lists