ACK: [SRU][Bionic][PATCH 0/5] Fixes for LP1799184 [v2]
stefan.bader at canonical.com
Wed Nov 7 13:43:25 UTC 2018
On 07.11.18 14:11, Frank Heimes wrote:
> I can leave some reasons I am aware of here - but if this should not be
> sufficient I may reached out to our Partner and ask there for a statement, too.
> This functionality is used in a closed solution that was heavily tested before GA.
> This testing of course incl. the kernel, hence testing was done on 4.4 (testing
> of kernel and req. user-space tools, partly close to kernel).
> Since the solution is closed it's not simply possible to do updates or kernel
> upgrades at any time.
> But using the HWE kernel would force one into a strict update pattern that not
> necessarily fits to the general solution update and release cycle.
> And even if HWE is used the entire test on kernel 4.4 would need to be redone on
> HWE again - which would req. a bigger repeating effort.
> So due to the stability of the 4.4 (GA) kernel and the through testing, it's
> desired to add the functionality of this SRU this the default kernel,
> rather than moving one via the 4 needed upgrades of HWE kernel.sequence.
Ok, I guess that sounds reasonable. So given there has been a lot of testing on
this and due to things being limited to architectural code which has reasonable
chance of catching regressions in that HW environment, I think we can accept the
Acked-by: Stefan Bader <stefan.bader at canonical.com>
> On Wed, Nov 7, 2018 at 1:51 PM Stefan Bader <stefan.bader at canonical.com
> <mailto:stefan.bader at canonical.com>> wrote:
> On 02.11.18 20:29, Frank Heimes wrote:
> > BugLink: http://bugs.launchpad.net/bugs/1799184
> > == SRU Justification ==
> > 'APQN tags in the zcrypt device driver are required to support deterministic
> > driver binding'
> > With the introduction of KVM hw crypto virtualization (on s390x) the driver
> > bound to an AP queue device is no longer unique determined.
> > Therefore a deterministic hot plugging semantics of AP queues that may be
> > to multiple drivers is needed.
> > With the three listed commits here it will be possible to configure an AP
> > (APQN) as being bound to a particular driver even if the associate hw gets
> > intermittently lost and reconnected.
> > == Fix ==
> > ac2b96f351d7d222 ("s390/zcrypt: code beautify")
> > 7e0bdbe5c21cb831 ("s390/zcrypt: AP bus support for alternate driver(s)")
> > 3d8f60d38e249f98 ("s390/zcrypt: hex string mask improvements for apmask
> and aqmask")
> > pre-reqs:
> > 2c957a8ad45 ("s390/zcrypt: remove unused functions and declarations")
> > 4a07750ba8f3f ("s390/zcrypt: Show load of cards and queues in sysfs")
> > == Regression Potential ==
> > Llow. because:
> > - There are quite some changes, but everything is limited to s390/zcrypt,
> > arch/s390/include/uapi/asm/*
> > and
> > drivers/s390/crypto/*
> > - So everything is s390x specific.
> > - And larger parts of the changes are beautifications.
> > - It's all upstream accepted in 4.19
> > - The code is already successfully test, integrated and running in cosmic.
> The main question remains why support for a new feature has to be pulled into a
> stable/released kernel version and is not done via HWE kernels. I would at least
> like to see some effort being made to come up with good reasons.
> > == Test Case ==
> > On an LPAR that has access to an CryptoExpress card,
> > execute the 'lszcrypt --verbose'
> > and check availability of:
> > /sys/bus/ap/apmask
> > General test and verification was btw. also done by IBM.
> > Please notice that the code already landed in cosmic.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the kernel-team