[SRU][Bionic][PATCH 0/5] Fixes for LP1799184 [v2]

Frank Heimes frank.heimes at canonical.com
Wed Nov 7 13:11:28 UTC 2018


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.




On Wed, Nov 7, 2018 at 1:51 PM Stefan Bader <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 bound
> > to multiple drivers is needed.
> > With the three listed commits here it will be possible to configure an
> AP queue
> > (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, means:
> >    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.
>
> -Stefan
>
> >
> > == 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20181107/8b06b8c8/attachment.html>


More information about the kernel-team mailing list