Ubuntu supports NVMe Multipath on all architectures in Focal. I know that some other distributions do not.
Setting nvme-core.multipath=0 for s390x isos only, or changing kernel config to disable multipath to "n" on s390x only, would mean regression on s390x as compared with amd64/arm64/ppc64le. That would be suboptimal. Do you have no plans to support multipath NVMe and are customers who buy expensive multipath capable NVMe drives will not be able to use multipath capability with them? Or for example is multipath handled separately on Z with NVMe? (ie. HMC mediated) My preference would be to see a chreipl fix upstream in s390-tools to add support for multipath nvme drives, and SRU that too. -- 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
