mbox series

[0/4] cxl: Add a firmware update mechanism and cxl_test emulation

Message ID 20230421-vv-fw_update-v1-0-22468747d72f@intel.com
Headers
Series cxl: Add a firmware update mechanism and cxl_test emulation |

Message

Verma, Vishal L April 22, 2023, 3:09 a.m. UTC 
  Add firmware update capability to the CXL memdev driver, and emulation
in cxl_test. Since the 'Transfer FW' mailbox command is a background
command, this series depends on the initial background command support
patches[1] from Davidlohr. These patches (patch 1 and 2) are included
in this series, unchanged, for reference.

Since the Transfer FW command can be a long-running background command,
it is desirable to retain kernel control over it, so that one command
doesn't monopolize the mailbox interface. The sysfs based firmware
loader mechanism that was developed for FPGAs is a suitable candidate to
help accomplish this. Patch 3 goes into more details on this.

The poll interval for the Transfer FW command is arbitrarily set at 1
second, and a poll count of 300, giving us a total wait time of five
minutes before which each slice of the transfer times out. This seems
like a good mix of responsiveness and a total wait - the spec doesn't
have any guidance on any upper or lower bounds for this. This likely
does not need to be user-configurable, so for now it is just hard-coded
in the driver.

Patch 4 implements the emulation of firmware update related commands in
the cxl_test environment to enable unit testing.

[1]: https://lore.kernel.org/linux-cxl/20230421092321.12741-1-dave@stgolabs.net

Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---
Davidlohr Bueso (2):
      cxl/pci: Allocate irq vectors earlier in pci probe
      cxl/mbox: Add background cmd handling machinery

Vishal Verma (2):
      cxl: add a firmware update mechanism using the sysfs firmware loader
      tools/testing/cxl: add firmware update emulation to CXL memdevs

 drivers/cxl/cxl.h                       |   7 +
 drivers/cxl/cxlmem.h                    |  84 +++++++++
 drivers/cxl/core/mbox.c                 |   4 +-
 drivers/cxl/core/memdev.c               | 324 ++++++++++++++++++++++++++++++++
 drivers/cxl/pci.c                       | 112 ++++++++++-
 tools/testing/cxl/test/mem.c            | 191 +++++++++++++++++++
 Documentation/ABI/testing/sysfs-bus-cxl |  11 ++
 drivers/cxl/Kconfig                     |   1 +
 8 files changed, 728 insertions(+), 6 deletions(-)
---
base-commit: 24b18197184ac39bb8566fb82c0bf788bcd0d45b
change-id: 20230421-vv-fw_update-59e35ad0d018

Best regards,

Comments

Davidlohr Bueso April 24, 2023, 5:39 p.m. UTC | #1 
On Fri, 21 Apr 2023, Vishal Verma wrote:

>The poll interval for the Transfer FW command is arbitrarily set at 1
>second, and a poll count of 300, giving us a total wait time of five
>minutes before which each slice of the transfer times out. This seems
>like a good mix of responsiveness and a total wait - the spec doesn't
>have any guidance on any upper or lower bounds for this. This likely
>does not need to be user-configurable, so for now it is just hard-coded
>in the driver.

Nothing against this, just thinking that in general, but we should
probably limit the poll interval to CXL_MAILBOX_TIMEOUT_MS. I'm not
sure, however, what would be a proper value across all commands. Or
would having this limit be per-cmd make more sense instead?

Thanks,
Davidlohr
Verma, Vishal L June 2, 2023, 5:48 p.m. UTC | #2 
On Mon, 2023-04-24 at 10:39 -0700, Davidlohr Bueso wrote:
> On Fri, 21 Apr 2023, Vishal Verma wrote:
> 
> > The poll interval for the Transfer FW command is arbitrarily set at 1
> > second, and a poll count of 300, giving us a total wait time of five
> > minutes before which each slice of the transfer times out. This seems
> > like a good mix of responsiveness and a total wait - the spec doesn't
> > have any guidance on any upper or lower bounds for this. This likely
> > does not need to be user-configurable, so for now it is just hard-coded
> > in the driver.
> 
> Nothing against this, just thinking that in general, but we should
> probably limit the poll interval to CXL_MAILBOX_TIMEOUT_MS. I'm not
> sure, however, what would be a proper value across all commands. Or
> would having this limit be per-cmd make more sense instead?
> 
Sorry I missed this comment earlier - are these actually related? The
mailbox timeout just waits for the doorbell, which in the case of a
background command would just indicate successful submission. The poll
interval is just how frequently we want to check the status of the
background command. I assume this could be set to something longer than
the mailbox ready timeout, especially if we know it will be a long
running command.