After some additional discussions the situation is as following:
With picking the current s390-tools fix (as it was used so far here) we would 
be on the same level (regarding NVMe support) than groovy.
The NVMe testing on groovy was done on a device without multipath.
The issue that cropped up during the testing on focal now is because an NVMe 
device with multipath was used.
But there is still value of getting the fixes picked up as they are (especially 
for a certain team).

However, getting NVMe devices supported also the multipath way and by the 
installer, the fix is of course still needed (chreipl).
But since this fix is not only needed for focal, but at least also for groovy 
(and probably also for hirsute), I think it's fine to drive this missing bit a 
later stage, based on a separate ticket and dedicated s390-tools package SRU.

(Please keep in mind that this is all s390x specific!)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1902179

Title:
  [20.04 FEAT] Support/enhancement of NVMe IPL

Status in Ubuntu on IBM z Systems:
  In Progress
Status in linux package in Ubuntu:
  Fix Released
Status in s390-tools package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  Fix Released
Status in s390-tools source package in Focal:
  New
Status in linux source package in Groovy:
  Fix Released
Status in s390-tools source package in Groovy:
  Fix Released
Status in linux source package in Hirsute:
  Fix Released
Status in s390-tools source package in Hirsute:
  Fix Released

Bug description:
  SRU Justification: (focal)
  ==================

  [Impact]

  * The base for being able to IPL (boot) NVMe devices on s390x was
  introduced with kernel 5.8.

  * This got now requested (for hardware enablement reasons) for Ubuntu
  20.04 LTS as well.

  * On top a brand new commit got upstream accepted that introduces
  support for NVMe IPL kernel parameters, which is not yet in groovy.

  [Fix]

  * cherry pick of commit 3737e8ee4f2fc7e77994d1a8bd618a9dda5a5514
  3737e8ee4f2f "s390: nvme ipl"

  * cherry pick of commit 23a457b8d57dc8d0cc1dbd1882993dd2fcc4b0c0 23a457b8d57d 
"s390: nvme reipl"
    does not apply cleanly, hence the following backport:
    
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1902179/+attachment/5430310/+files/0002-s390-nvme-reipl.patch

  * cherry pick of commit d9f12e48d08ec08ace574050a838e001e442ee38
  d9f12e48d08e "s390/ipl: support NVMe IPL kernel parameters"

  [Test Case]

  * IBM z15 or LinuxONE III hardware is needed with an NVMe device
  attached to a LPAR.

  * Install the patched kernel on focal/20.04 installation and make sure
  that zipl re-ran (the patched version of zipl with the s390-tools
  commit mentioned in this LP bug - or take the s390-tools version for
  groovy for testing purposes).

  * If everything is in place (means patched kernel, as well as patched 
s390-tools/zipl) an installation from scratch on an NVMe devices should be 
possible - in case everything needed landed on an updated image.
    With the 20.04.2 image that should be the case.

  [Regression Potential]

  * There is a certain regression risk with these patches, because:

  * the 'zipl' (s390x-specific) boot-loader is touched

  * if something is wrong there, in worst-case systems where the
  modified zipl ran may no longer be bootable!

  * The modifications are targetted towards nvme devices ('blkext'
  driver), but they are closely related to zFCP devices and share some
  code parts,

  * hence in worst case they could have an impact on zFCP devices, too.

  * But this is very unlikely, since a (largely) separate IPL type
  'nvme' got introduced and NVMe ipl is handled in separate case
  statements and functions.

  * The patches are all upstream accepted (the first two with 5.8, that
  last with v5.10-rc1, hence the latter one is as of today in linux-
  next).

  * A patched focal kernel was build and shared for further testing. I
  did some regression testing with the patched kernel on non-NVMe
  systems - the NVMe based tests need to be done by IBM (due to the lack
  of hardware).

  * All modifications are limited to the s390x architecture and there
  again to the unique way of booting aka IPL
  (arch/s390/include/asm/ipl.h, arch/s390/include/uapi/asm/ipl.h,
  arch/s390/kernel/ipl.c and arch/s390/boot/ipl_parm.c).

  [Other]

  * The general NVMe ipl (boot) functionality in given with 3737e8ee4f2f
  "s390: nvme ipl" and 23a457b8d57d "s390: nvme reipl" and is already
  proven to work with groovy.

  * New for groovy AND focal is only "s390/ipl: support NVMe IPL kernel
  parameters".

  * The entire set of commits/patches is only new for focal.

  * The SRU for SRUing "s390/ipl: support NVMe IPL kernel parameters" to
  groovy/20.10 was handled by a separate request.

  _________________________

  
  SRU Justification: (groovy)
  ==================

  [Impact]

  * The basics for being able to IPL (boot) from NVMe devices on s390x
  were introduced with kernel 5.8.

  * This was tested and is proven to work with groovy.

  * Now a patch was requested to be added to groovy that introduces
  support for NVMe IPL kernel parameters.

  [Fix]

  * d9f12e48d08ec08ace574050a838e001e442ee38 d9f12e48d08e "s390/ipl:
  support NVMe IPL kernel parameters"

  [Test Case]

  * IBM z15 or LinuxONE III hardware is needed with an NVMe device
  attached to a LPAR.

  * Just check if NVMe kernel parameters can be passed over.

  * Due to the lack of hardware this test needs to be done by IBM.

  [Regression Potential]

  * There is a certain regression risk with this patch, since:

  * The handling of 'scpdata' is changed, and with that the way how
  kernel cmd-line parameters are extracted from the NVMe IPL block, that
  is passed by the firmware to the kernel at boot time.

  * If broken such a hand over will not work for NVMe anymore - which
  wouldn't be a very big problem for now, since booting w/o still works
  fine (as it does today).

  * But in worst case it could break the hand over of cmd-line
  parameters for FCP devices, since some code is shared or even harm ipl
  in general.

  * The patch is upstream accepted (with v5.10-rc1 - as of today in
  linux-next) and a patched groovy kernel was build and shared for
  further testing.

  * All modifications are limited to the s390x architecture and there
  again to the unique way of booting aka IPL (s390/boot/ipl*).

  [Other]

  * This is in preparation for getting IPL (boot) from NVMe device
  support on s390x backported to focal (for hardware enablement
  reasons).

  * Without having this patch in groovy, one may face a regression
  during upgrade from groovy to focal.

  * Since it's planned to have the hirsute kernel on 5.1x, it will have
  this patch sooner or later.

  * However, since the today's hirsute kernel is just based on groovy,
  I've added hirsute to the SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1902179/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to