From: Gregory Price <gregory.price@memverge.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Jonathan Cameron via <qemu-devel@nongnu.org>,
Lukas Wunner <lukas@wunner.de>, Michael Tsirkin <mst@redhat.com>,
Ben Widawsky <bwidawsk@kernel.org>,
linux-cxl@vger.kernel.org, linuxarm@huawei.com,
Ira Weiny <ira.weiny@intel.com>,
Gregory Price <gourry.memverge@gmail.com>,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: cxl nvdimm Potential probe ordering issues.
Date: Thu, 19 Jan 2023 23:53:53 -0500 [thread overview]
Message-ID: <Y8oeYfyqNuSIIxCt@memverge.com> (raw)
In-Reply-To: <20230119150449.000037f2@huawei.com>
On Thu, Jan 19, 2023 at 03:04:49PM +0000, Jonathan Cameron wrote:
> Gregory, would you mind checking if
> cxl_nvb is NULL here...
> https://elixir.bootlin.com/linux/v6.2-rc4/source/drivers/cxl/pmem.c#L67
> (printk before it is used should work).
>
> Might also be worth checking cxl_nvd and cxl_ds
> but my guess is cxl_nvb is our problem (it is when I deliberate change
> the load order).
>
> Jonathan
>
This is exactly the issue. cxl_nvb is null, the rest appear fine.
Also, note, that weirdly the non-volatile bridge shows up when launching
this in volatile mode, but no stack trace appears.
¯\_(ツ)_/¯
After spending way too much time tracing through the current cxl driver
code, i have only really determined that
1) The code is very pmem oriented, and it's unclear to me how the driver
as-is differentiates a persistent device from a volatile device. That
code path still completely escapes me. The only differentiating code
i see is in the memdev probe path that creates mem#/pmem and mem#/ram
2) The code successfully manages probe, enable, and mount a REAL device
- cxl memdev appears (/sys/bus/cxl/devices/mem0)
- a dax device appears (/sys/bus/dax/devices/)
This happens at boot, which I assume must be bios related
- The memory *does not* auto-online, instead the dax device can be
onlined as system-ram *manually* via ndctl and friends
3) The code creates an nvdimm_bridge IFF a CFMW is defined - regardless
of the type-3 device configuration (pmem-only or vmem-only)
# CFMW defined
[root@fedora ~]# ls /sys/bus/cxl/devices/
decoder0.0 decoder2.0 mem0 port1
decoder1.0 endpoint2 nvdimm-bridge0 root0
# CFMW not defined
[root@fedora ~]# ls /sys/bus/cxl/devices/
decoder1.0 decoder2.0 endpoint2 mem0 port1 root0
4) As you can see above, multiple decoders are registered. I'm not sure
if that's correct or not, but it does seem odd given there's only one
cxl type-3 device. Odd that decoder0.0 shows up when CFMW is there,
but not when it isn't.
Note: All these tests have two root ports:
-device pxb-cxl,id=cxl.0,bus=pcie.0,bus_nr=52 \
-device cxl-rp,id=rp0,bus=cxl.0,chassis=0,port=0,slot=0 \
-device cxl-rp,id=rp1,bus=cxl.0,chassis=0,port=1,slot=1 \
Don't know why I haven't thought of this until now, but is the CFMW code
reporting something odd about what's behind it? Is it assuming the
devices are pmem?
next prev parent reply other threads:[~2023-01-20 5:08 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 14:24 [PATCH 0/8] hw/cxl: CXL emulation cleanups and minor fixes for upstream Jonathan Cameron
2023-01-11 14:24 ` [PATCH 1/8] hw/mem/cxl_type3: Improve error handling in realize() Jonathan Cameron
2023-01-11 17:33 ` Ira Weiny
2023-01-11 14:24 ` [PATCH 2/8] hw/pci-bridge/cxl_downstream: Fix type naming mismatch Jonathan Cameron
2023-01-11 14:45 ` Philippe Mathieu-Daudé
2023-01-11 17:38 ` Ira Weiny
2023-01-11 14:24 ` [PATCH 3/8] hw/cxl: set cxl-type3 device type to PCI_CLASS_MEMORY_CXL Jonathan Cameron
2023-01-11 17:41 ` Ira Weiny
2023-01-11 14:24 ` [PATCH 4/8] hw/cxl: Add CXL_CAPACITY_MULTIPLIER definition Jonathan Cameron
2023-01-11 15:48 ` Philippe Mathieu-Daudé
2023-01-11 14:24 ` [PATCH 5/8] hw/i386/acpi: Drop duplicate _UID entry for CXL root bridge Jonathan Cameron
2023-01-11 17:48 ` Ira Weiny
2023-01-11 14:24 ` [PATCH 6/8] qemu/bswap: Add const_le64() Jonathan Cameron
2023-01-11 15:49 ` Philippe Mathieu-Daudé
2023-01-11 16:07 ` Philippe Mathieu-Daudé
2023-01-11 16:33 ` Philippe Mathieu-Daudé
2023-01-11 16:40 ` Philippe Mathieu-Daudé
2023-01-11 16:59 ` Jonathan Cameron
2023-01-11 14:24 ` [PATCH 7/8] qemu/uuid: Add UUID static initializer Jonathan Cameron
2023-01-11 14:24 ` [PATCH 8/8] hw/cxl/mailbox: Use new UUID network order define for cel_uuid Jonathan Cameron
2023-01-11 15:50 ` Philippe Mathieu-Daudé
2023-01-12 15:39 ` [PATCH 0/8] hw/cxl: CXL emulation cleanups and minor fixes for upstream Gregory Price
2023-01-12 17:21 ` Jonathan Cameron
2023-01-12 22:46 ` Gregory Price
2023-01-13 9:12 ` Jonathan Cameron
2023-01-13 14:19 ` Gregory Price
2023-01-13 14:40 ` Jonathan Cameron
2023-01-13 14:45 ` Jonathan Cameron
2023-01-13 15:12 ` Lukas Wunner
2023-01-13 15:42 ` Gregory Price
2023-01-18 19:22 ` Gregory Price
2023-01-18 19:31 ` Gregory Price
2023-01-19 12:42 ` Jonathan Cameron
2023-01-19 15:04 ` cxl nvdimm Potential probe ordering issues Jonathan Cameron
2023-01-19 16:17 ` Jonathan Cameron
2023-01-20 5:51 ` Gregory Price
2023-01-20 17:26 ` Dan Williams
2023-01-20 4:53 ` Gregory Price [this message]
2023-01-20 10:47 ` Jonathan Cameron
2023-01-20 17:38 ` Dan Williams
2023-01-20 21:54 ` Gregory Price
2023-01-20 22:41 ` Dan Williams
2023-01-23 9:44 ` Jonathan Cameron
2023-01-23 18:16 ` Gregory Price
2023-01-19 10:19 ` [PATCH 0/8] hw/cxl: CXL emulation cleanups and minor fixes for upstream Jonathan Cameron
2023-01-19 11:48 ` Michael S. Tsirkin
2023-01-19 12:16 ` Jonathan Cameron
2023-01-19 14:23 ` Gregory Price
2023-01-19 14:20 ` Gregory Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8oeYfyqNuSIIxCt@memverge.com \
--to=gregory.price@memverge.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=bwidawsk@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=gourry.memverge@gmail.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lukas@wunner.de \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox