All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: "Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>,
	"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>
Cc: 'Dan Williams' <dan.j.williams@intel.com>
Subject: RE: Questions about CXL device (type 3 memory) hotplug
Date: Mon, 22 May 2023 17:11:39 -0700	[thread overview]
Message-ID: <646c04bbbd96_33fb32944b@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <TYWPR01MB10082116669BA002263DF132A90439@TYWPR01MB10082.jpnprd01.prod.outlook.com>

Yasunori Gotou (Fujitsu) wrote:
> Hello,
> 
> I have some questions about CXL device hotplug (especially type 3 memory device).
> 
> Though my team members still need to work for a remain issue of Filesystem-DAX,
> or RDMA for persistent memory yet, I would like to move some of them for
> CXL type 3 memory device after finish the above works.
> This is preparation for it. I would like to confirm current status of CXL
> type 3 memory hotplug.
> 
> Q1) Can PCIe hotplug driver detect and call CXL driver?
> 
>     CXL specification says as follows
>     "9.9 Hot-Plug"
>     "CXL leverages PCIe Hot-plug model and Hot-plug elements as defined in PCIe
>     BaseSpecification and the applicable form-factor specifications."
> 
>     At a glance, PCIe hotplug driver seems to be able to detect any PCIe
>     hotpluged device, and call its suitable probe/attach function. But I'm new
>     around here, and  I'm not sure it can actually call the suitable CXL driver.
> 
>     Can PCIe hotplug driver recognize a CXL device and call its driver?

Yes.

The cxl_pci driver (drivers/cxl/pci.c) is just a typical PCI driver as
far as the PCI hotplug driver is concerned. So add/remove events of a
CXL card get turned into probe()/remove() events on the driver.

> 
> Q2) Can QEMU/KVM emulate CXL device hotplug?
> 
>    I heard that QEMU/KVM has PCIe device hotplug emulation, but I'm not sure
>    it can hotplug CXL device.

It can, but as far as the driver is concerned you can achieve the same
by:

echo $devname > /sys/bus/pci/drivers/cxl_pci/unbind

...that exercises the same software flows as physical unplug.

> 
> Q3) After called CXL driver and detected a CXL type 3 memory device,
>     what sequence is/will be executed?
> 
>     IIRC, kernel created /sys/devices/system/memory/memoryNNN directories when
>     memory device is recognized. Then, online operation was executed by 
>     a user or an application.
>     
>     However, CXL specification seems to require more configuration like
>     interleave, region, and namespace by Fabric Manager (cxl command?)
>     after device detection before memory online.
> 
>     So, my understanding is that the above configuration must be executed
>     after device detection, and before memory online. Is it correct?

Correct, after the device is added and the driver attaches there is
still a step needed to configure a CXL region.

For now that step is to manually run:

cxl create-region

...later we might consider some udev rules to automatically assemble
regions from discovered capacity.

> Q4) Current CXL drivers/tools support Hot-removal request from PCIe?
> 
>     CXL specification says "In a managed Hot-Remove flow, software is
>     notified of a hot removal request."

Currently there is a requirement that:

cxl disable-memdev

...is run before the device can be removed. There is no warning from the
PCI hotplug driver. Which means that if end user does the wrong sequence
they can crash the kernel / remove memory that may still be in active
use.

>     I think that CXL drivers/tools need to find which sections belongs to the
>     requested device, and execute offline them at least. In addition,
>     Fabric Manager may need to prepare removing the device due to configuration
>     change.
> 
>     Does current CXL drivers/tools can execute them?
>     Otherwise, does it need to be implemented yet?

Currently the 'cxl disable-memdev' command is not smart about
determining when the device is in active use it just claims that it is
always in use. That is in progress to be improved.

> Q5) How CXL driver treat region/namespace size against section size?
>     Current x86-64 section size can be 2Gbyte, but CXL region size may be
>     able to smaller than it. 

The section size is still 128MB, the hotplug memory block size is what
expands to 2GB. That size limits what can be onlined via the dax_kmem
driver.

  reply	other threads:[~2023-05-23  0:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22  8:06 Questions about CXL device (type 3 memory) hotplug Yasunori Gotou (Fujitsu)
2023-05-23  0:11 ` Dan Williams [this message]
2023-05-23  8:31   ` Yasunori Gotou (Fujitsu)
2023-05-23 17:36     ` Dan Williams
2023-05-24 11:12       ` Yasunori Gotou (Fujitsu)
2023-05-24 20:51         ` Dan Williams
2023-05-25 10:32           ` Yasunori Gotou (Fujitsu)
2023-05-26  8:05         ` Yasunori Gotou (Fujitsu)
2023-05-26 14:48           ` Dan Williams
2023-05-29  8:07             ` Yasunori Gotou (Fujitsu)
2023-06-06 17:58               ` Dan Williams
2023-06-08  7:39                 ` Yasunori Gotou (Fujitsu)
2023-06-08 18:37                   ` Dan Williams
2023-06-09  1:02                     ` Yasunori Gotou (Fujitsu)
2023-05-23 13:34   ` Vikram Sethi
2023-05-23 18:40     ` Dan Williams
2023-05-24  0:02       ` Vikram Sethi
2023-05-24  4:03         ` Dan Williams
2023-05-24 14:47           ` Vikram Sethi
2023-05-24 21:20             ` Dan Williams
2023-05-31  4:25               ` Vikram Sethi
2023-06-06 20:54                 ` Dan Williams
2023-06-07  1:06                   ` Vikram Sethi
2023-06-07 15:12                     ` Jonathan Cameron
2023-06-07 18:44                       ` Vikram Sethi
2023-06-08 15:19                         ` Jonathan Cameron
2023-06-08 18:41                           ` Dan Williams
2024-03-27  7:10   ` Yuquan Wang
2024-03-27  7:18   ` Yuquan Wang

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=646c04bbbd96_33fb32944b@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=y-goto@fujitsu.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.