Re: [SPDK] firmware update

* Re: [SPDK] firmware update
@ 2018-09-13 16:37 Walker, Benjamin
  0 siblings, 0 replies; 3+ messages in thread
From: Walker, Benjamin @ 2018-09-13 16:37 UTC (permalink / raw)
  To: spdk

[-- Attachment #1: Type: text/plain, Size: 3962 bytes --]

On Thu, 2018-09-13 at 13:48 +0000, Nabarro, Tom wrote:
> Is anyone using the firmware update capability through SPDK to update Intel
> NVMe SSDs? I've been using the API to perform upgrades on specific firmware
> version combinations but I'm not sure it can be used as a general approach.
> 
> For background we were hoping to be able to offer a management interface
> feature which enabled programmatic firmware upgrades (through the SPDK API)
> without relying on specialized commandline interface sequences for each
> upgrade, but from some of the documentation regarding firmware updates for
> example the DC P4800X it seems like there might not be a general process for
> upgrading firmware on Intel NVMe SSDs and that specialized procedures are
> required for different firmware revision upgrade combinations.
> 
> There are obviously specialized cli tools for doing vendor specific upgrades
> but I was hoping this might be performed reliably through SPDK.
> 
> Maybe it just has to be offered as a raw feature which may cause unintended
> consequences and the validity of the specific upgrade and any required
> pre/post actions must be investigated first. Not a particularly compelling
> caveat for a management application but may be necessary.
> 
> Any thoughts would be much appreciated.

SPDK implements the NVMe specification's standardized mechanism for updating
device firmware. For devices that can be updated using the standard commands,
SPDK will do the job (see 
http://spdk.io/doc/nvme_8h.html#a7938b258a7614073065be4f6a35bd0e2, which I'm
sure is what you are already calling). Relying on the standard commands is the
only way to create a simple general purpose firmware update tool.

Unfortunately, I'm aware that many (if not most) devices require vendor specific
commands in order to properly update firmware. Further, the exact sequence of
vendor specific commands a device needs is often not publicly documented. While
vendor specific commands are a part of the specification, using them to
circumvent the standardized firmware update mechanism does not seem like their
intended purpose to me. That unfortunate reality means that a simple and future-
proof general purpose tool for updating NVMe drive firmware is just not
possible.

SPDK does have a way to send a raw command, as you mentioned, which could be a
vendor specific command. A tool could use that API to send the proper sequence
of vendor-specific commands for a given device. This is what most of the
specialized cli tools do (just using ioctl instead of SPDK), so those same
specialized cli tools could be ported to use SPDK instead. That seems like it is
probably the only way forward. I'd certainly consider adding new quirks to the
SPDK NVMe driver (see lib/nvme/nvme_quirks.c) that change the behavior of
spdk_nvme_ctrlr_update_firmware() for certain devices to instead do whatever
sequence of vendor specific commands is actually required, if you or someone
else were to submit a patch for it. Then software using SPDK could use a
consistent API and be abstracted away from the details of how exactly the
firmware update needs to occur. This strategy would require vendors to disclose
the proper sequence of vendor-specific commands to send for each device.

> 
> Tom
> 
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 3+ messages in thread