mbox series

[SRU,N,J,0/1] s390/cpum_cf: make crypto counters upward compatible (LP: 2074380)

Message ID 20240801105355.547635-1-frank.heimes@canonical.com
Headers show
Series s390/cpum_cf: make crypto counters upward compatible (LP: 2074380) | expand

Message

Frank Heimes Aug. 1, 2024, 10:53 a.m. UTC
BugLink: https://bugs.launchpad.net/bugs/2074380

SRU Justification:

[ Impact ]

 * The CPU Measurement Facility (CPU MF) crypto counter set
   is not listed in the device sysfs tree - it's not exported
   in the sysfs directory /sys/devices/cpum_cf/events.

 * The attribute files for each CPU-MF counter defined
   in the crypto counter set is missing.

 * This is caused by the counter second version number of CPU MF
   hardware being incremented on new machines.

 * This causes a sanity check to fail,
   but the counters are supported by hardware.

 * The solution is to remove the upper limit in counter second
   version number check.

[ Fix ]

 * f10933cbd2df f10933cbd2dfddf6273698a45f76db9bafd8150f
   "s390/cpum_cf: make crypto counters upward compatible across machine types"

 * The fix was upstream accepted with kernel v6.10(-rc1).

 * Upstream commit applies cleanly on noble master-next,
   but needed to be backported to jammy master-next due to different code
   and context in kernel 5.15.

[ Test Plan ]

 * Run the following commands on a new machine generation:
   (hence only doable by IBM)
   # ls -l /sys/devices/cpum_cf/events/ | grep AES

 * If the output is empty than this patch is required.

 * With a patched kernel the output should be like:
   # ls /sys/devices/cpum_cf/events/ | grep AES
   AES_BLOCKED_CYCLES
   AES_BLOCKED_FUNCTIONS
   AES_CYCLES
   AES_FUNCTIONS

[ Where problems could occur ]

 * This affects s390x only - CPU MF is s390-specific,
   and only s390 specific code is modified.

 * And it furthermore is limited to the crypto counter set
   of CPU MF.

 * So any impact is likely limited to hardware crypto counters
   on s390x only.

 * In s390/kernel/perf_cpum_cf.c the else if case got changed from
   explicitly checking for 6 or 7 to >= 6 which seems to require
   attention for future 8 and more cases.

 * In s390/kernel/perf_cpum_cf_events.c the switch (ci.csvn) statement
   was changed to an if / else if with similar logic.
   Again attentioin for any potential future cases >= 8.

 * It does not look like currently used cases (1..5 and 6..7)
   are affected by the modification, just >7.

 * Test build of patched jammy and noble s390x kernels were build
   and are avaiable here:
   https://launchpad.net/~fheimes/+archive/ubuntu/lp2074380

[ Other Info ]

 * Since the code/fix was upstream accepted with kernel v6.10(-rc1)
   it does not affect the current development release oracular.

 * This SRU can also be seen under the umbrella of new
    hardware enablement.

 * Since it requires special hw, the verification needs to be
   done by IBM.

Thomas Richter (1):
  s390/cpum_cf: make crypto counters upward compatible across machine
    types

 arch/s390/kernel/perf_cpum_cf.c        |  2 +-
 arch/s390/kernel/perf_cpum_cf_events.c | 11 +++--------
 2 files changed, 4 insertions(+), 9 deletions(-)

Comments

Kevin Becker Aug. 1, 2024, 3:13 p.m. UTC | #1
On Thu, Aug 1, 2024 at 6:54 AM <frank.heimes@canonical.com> wrote:
>
> BugLink: https://bugs.launchpad.net/bugs/2074380
>
> SRU Justification:
>
> [ Impact ]
>
>  * The CPU Measurement Facility (CPU MF) crypto counter set
>    is not listed in the device sysfs tree - it's not exported
>    in the sysfs directory /sys/devices/cpum_cf/events.
>
>  * The attribute files for each CPU-MF counter defined
>    in the crypto counter set is missing.
>
>  * This is caused by the counter second version number of CPU MF
>    hardware being incremented on new machines.
>
>  * This causes a sanity check to fail,
>    but the counters are supported by hardware.
>
>  * The solution is to remove the upper limit in counter second
>    version number check.
>
> [ Fix ]
>
>  * f10933cbd2df f10933cbd2dfddf6273698a45f76db9bafd8150f
>    "s390/cpum_cf: make crypto counters upward compatible across machine types"
>
>  * The fix was upstream accepted with kernel v6.10(-rc1).
>
>  * Upstream commit applies cleanly on noble master-next,
>    but needed to be backported to jammy master-next due to different code
>    and context in kernel 5.15.
>
> [ Test Plan ]
>
>  * Run the following commands on a new machine generation:
>    (hence only doable by IBM)
>    # ls -l /sys/devices/cpum_cf/events/ | grep AES
>
>  * If the output is empty than this patch is required.
>
>  * With a patched kernel the output should be like:
>    # ls /sys/devices/cpum_cf/events/ | grep AES
>    AES_BLOCKED_CYCLES
>    AES_BLOCKED_FUNCTIONS
>    AES_CYCLES
>    AES_FUNCTIONS
>
> [ Where problems could occur ]
>
>  * This affects s390x only - CPU MF is s390-specific,
>    and only s390 specific code is modified.
>
>  * And it furthermore is limited to the crypto counter set
>    of CPU MF.
>
>  * So any impact is likely limited to hardware crypto counters
>    on s390x only.
>
>  * In s390/kernel/perf_cpum_cf.c the else if case got changed from
>    explicitly checking for 6 or 7 to >= 6 which seems to require
>    attention for future 8 and more cases.
>
>  * In s390/kernel/perf_cpum_cf_events.c the switch (ci.csvn) statement
>    was changed to an if / else if with similar logic.
>    Again attentioin for any potential future cases >= 8.
>
>  * It does not look like currently used cases (1..5 and 6..7)
>    are affected by the modification, just >7.
>
>  * Test build of patched jammy and noble s390x kernels were build
>    and are avaiable here:
>    https://launchpad.net/~fheimes/+archive/ubuntu/lp2074380
>
> [ Other Info ]
>
>  * Since the code/fix was upstream accepted with kernel v6.10(-rc1)
>    it does not affect the current development release oracular.
>
>  * This SRU can also be seen under the umbrella of new
>     hardware enablement.
>
>  * Since it requires special hw, the verification needs to be
>    done by IBM.
>
> Thomas Richter (1):
>   s390/cpum_cf: make crypto counters upward compatible across machine
>     types
>
>  arch/s390/kernel/perf_cpum_cf.c        |  2 +-
>  arch/s390/kernel/perf_cpum_cf_events.c | 11 +++--------
>  2 files changed, 4 insertions(+), 9 deletions(-)
>
> --

Acked-by: Kevin Becker <kevin.becker@canonical.com>
Manuel Diewald Aug. 1, 2024, 3:51 p.m. UTC | #2
On Thu, Aug 01, 2024 at 12:53:53PM +0200, frank.heimes@canonical.com wrote:
> BugLink: https://bugs.launchpad.net/bugs/2074380
> 
> SRU Justification:
> 
> [ Impact ]
> 
>  * The CPU Measurement Facility (CPU MF) crypto counter set
>    is not listed in the device sysfs tree - it's not exported
>    in the sysfs directory /sys/devices/cpum_cf/events.
> 
>  * The attribute files for each CPU-MF counter defined
>    in the crypto counter set is missing.
> 
>  * This is caused by the counter second version number of CPU MF
>    hardware being incremented on new machines.
> 
>  * This causes a sanity check to fail,
>    but the counters are supported by hardware.
> 
>  * The solution is to remove the upper limit in counter second
>    version number check.
> 
> [ Fix ]
> 
>  * f10933cbd2df f10933cbd2dfddf6273698a45f76db9bafd8150f
>    "s390/cpum_cf: make crypto counters upward compatible across machine types"
> 
>  * The fix was upstream accepted with kernel v6.10(-rc1).
> 
>  * Upstream commit applies cleanly on noble master-next,
>    but needed to be backported to jammy master-next due to different code
>    and context in kernel 5.15.
> 
> [ Test Plan ]
> 
>  * Run the following commands on a new machine generation:
>    (hence only doable by IBM)
>    # ls -l /sys/devices/cpum_cf/events/ | grep AES
> 
>  * If the output is empty than this patch is required.
> 
>  * With a patched kernel the output should be like:
>    # ls /sys/devices/cpum_cf/events/ | grep AES
>    AES_BLOCKED_CYCLES
>    AES_BLOCKED_FUNCTIONS
>    AES_CYCLES
>    AES_FUNCTIONS
> 
> [ Where problems could occur ]
> 
>  * This affects s390x only - CPU MF is s390-specific,
>    and only s390 specific code is modified.
> 
>  * And it furthermore is limited to the crypto counter set
>    of CPU MF.
> 
>  * So any impact is likely limited to hardware crypto counters
>    on s390x only.
> 
>  * In s390/kernel/perf_cpum_cf.c the else if case got changed from
>    explicitly checking for 6 or 7 to >= 6 which seems to require
>    attention for future 8 and more cases.
> 
>  * In s390/kernel/perf_cpum_cf_events.c the switch (ci.csvn) statement
>    was changed to an if / else if with similar logic.
>    Again attentioin for any potential future cases >= 8.
> 
>  * It does not look like currently used cases (1..5 and 6..7)
>    are affected by the modification, just >7.
> 
>  * Test build of patched jammy and noble s390x kernels were build
>    and are avaiable here:
>    https://launchpad.net/~fheimes/+archive/ubuntu/lp2074380
> 
> [ Other Info ]
> 
>  * Since the code/fix was upstream accepted with kernel v6.10(-rc1)
>    it does not affect the current development release oracular.
> 
>  * This SRU can also be seen under the umbrella of new
>     hardware enablement.
> 
>  * Since it requires special hw, the verification needs to be
>    done by IBM.
> 
> Thomas Richter (1):
>   s390/cpum_cf: make crypto counters upward compatible across machine
>     types
> 
>  arch/s390/kernel/perf_cpum_cf.c        |  2 +-
>  arch/s390/kernel/perf_cpum_cf_events.c | 11 +++--------
>  2 files changed, 4 insertions(+), 9 deletions(-)
> 
> -- 
> 2.34.1
> 
> 
> -- 
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

Acked-by: Manuel Diewald <manuel.diewald@canonical.com>
Andrei Gherzan Aug. 5, 2024, 12:50 p.m. UTC | #3
On 24/08/01 12:53pm, frank.heimes@canonical.com wrote:
> BugLink: https://bugs.launchpad.net/bugs/2074380
> 
> SRU Justification:
> 
> [ Impact ]
> 
>  * The CPU Measurement Facility (CPU MF) crypto counter set
>    is not listed in the device sysfs tree - it's not exported
>    in the sysfs directory /sys/devices/cpum_cf/events.
> 
>  * The attribute files for each CPU-MF counter defined
>    in the crypto counter set is missing.
> 
>  * This is caused by the counter second version number of CPU MF
>    hardware being incremented on new machines.
> 
>  * This causes a sanity check to fail,
>    but the counters are supported by hardware.
> 
>  * The solution is to remove the upper limit in counter second
>    version number check.
> 
> [ Fix ]
> 
>  * f10933cbd2df f10933cbd2dfddf6273698a45f76db9bafd8150f
>    "s390/cpum_cf: make crypto counters upward compatible across machine types"
> 
>  * The fix was upstream accepted with kernel v6.10(-rc1).
> 
>  * Upstream commit applies cleanly on noble master-next,
>    but needed to be backported to jammy master-next due to different code
>    and context in kernel 5.15.
> 
> [ Test Plan ]
> 
>  * Run the following commands on a new machine generation:
>    (hence only doable by IBM)
>    # ls -l /sys/devices/cpum_cf/events/ | grep AES
> 
>  * If the output is empty than this patch is required.
> 
>  * With a patched kernel the output should be like:
>    # ls /sys/devices/cpum_cf/events/ | grep AES
>    AES_BLOCKED_CYCLES
>    AES_BLOCKED_FUNCTIONS
>    AES_CYCLES
>    AES_FUNCTIONS
> 
> [ Where problems could occur ]
> 
>  * This affects s390x only - CPU MF is s390-specific,
>    and only s390 specific code is modified.
> 
>  * And it furthermore is limited to the crypto counter set
>    of CPU MF.
> 
>  * So any impact is likely limited to hardware crypto counters
>    on s390x only.
> 
>  * In s390/kernel/perf_cpum_cf.c the else if case got changed from
>    explicitly checking for 6 or 7 to >= 6 which seems to require
>    attention for future 8 and more cases.
> 
>  * In s390/kernel/perf_cpum_cf_events.c the switch (ci.csvn) statement
>    was changed to an if / else if with similar logic.
>    Again attentioin for any potential future cases >= 8.
> 
>  * It does not look like currently used cases (1..5 and 6..7)
>    are affected by the modification, just >7.
> 
>  * Test build of patched jammy and noble s390x kernels were build
>    and are avaiable here:
>    https://launchpad.net/~fheimes/+archive/ubuntu/lp2074380
> 
> [ Other Info ]
> 
>  * Since the code/fix was upstream accepted with kernel v6.10(-rc1)
>    it does not affect the current development release oracular.
> 
>  * This SRU can also be seen under the umbrella of new
>     hardware enablement.
> 
>  * Since it requires special hw, the verification needs to be
>    done by IBM.
> 
> Thomas Richter (1):
>   s390/cpum_cf: make crypto counters upward compatible across machine
>     types
> 
>  arch/s390/kernel/perf_cpum_cf.c        |  2 +-
>  arch/s390/kernel/perf_cpum_cf_events.c | 11 +++--------

Acked-by: Andrei Gherzan <andrei.gherzan@canonical.com>
Roxana Nicolescu Aug. 6, 2024, 1:35 p.m. UTC | #4
On 01/08/2024 12:53, frank.heimes@canonical.com wrote:
> BugLink: https://bugs.launchpad.net/bugs/2074380
>
> SRU Justification:
>
> [ Impact ]
>
>   * The CPU Measurement Facility (CPU MF) crypto counter set
>     is not listed in the device sysfs tree - it's not exported
>     in the sysfs directory /sys/devices/cpum_cf/events.
>
>   * The attribute files for each CPU-MF counter defined
>     in the crypto counter set is missing.
>
>   * This is caused by the counter second version number of CPU MF
>     hardware being incremented on new machines.
>
>   * This causes a sanity check to fail,
>     but the counters are supported by hardware.
>
>   * The solution is to remove the upper limit in counter second
>     version number check.
>
> [ Fix ]
>
>   * f10933cbd2df f10933cbd2dfddf6273698a45f76db9bafd8150f
>     "s390/cpum_cf: make crypto counters upward compatible across machine types"
>
>   * The fix was upstream accepted with kernel v6.10(-rc1).
>
>   * Upstream commit applies cleanly on noble master-next,
>     but needed to be backported to jammy master-next due to different code
>     and context in kernel 5.15.
>
> [ Test Plan ]
>
>   * Run the following commands on a new machine generation:
>     (hence only doable by IBM)
>     # ls -l /sys/devices/cpum_cf/events/ | grep AES
>
>   * If the output is empty than this patch is required.
>
>   * With a patched kernel the output should be like:
>     # ls /sys/devices/cpum_cf/events/ | grep AES
>     AES_BLOCKED_CYCLES
>     AES_BLOCKED_FUNCTIONS
>     AES_CYCLES
>     AES_FUNCTIONS
>
> [ Where problems could occur ]
>
>   * This affects s390x only - CPU MF is s390-specific,
>     and only s390 specific code is modified.
>
>   * And it furthermore is limited to the crypto counter set
>     of CPU MF.
>
>   * So any impact is likely limited to hardware crypto counters
>     on s390x only.
>
>   * In s390/kernel/perf_cpum_cf.c the else if case got changed from
>     explicitly checking for 6 or 7 to >= 6 which seems to require
>     attention for future 8 and more cases.
>
>   * In s390/kernel/perf_cpum_cf_events.c the switch (ci.csvn) statement
>     was changed to an if / else if with similar logic.
>     Again attentioin for any potential future cases >= 8.
>
>   * It does not look like currently used cases (1..5 and 6..7)
>     are affected by the modification, just >7.
>
>   * Test build of patched jammy and noble s390x kernels were build
>     and are avaiable here:
>     https://launchpad.net/~fheimes/+archive/ubuntu/lp2074380
>
> [ Other Info ]
>
>   * Since the code/fix was upstream accepted with kernel v6.10(-rc1)
>     it does not affect the current development release oracular.
>
>   * This SRU can also be seen under the umbrella of new
>      hardware enablement.
>
>   * Since it requires special hw, the verification needs to be
>     done by IBM.
>
> Thomas Richter (1):
>    s390/cpum_cf: make crypto counters upward compatible across machine
>      types
>
>   arch/s390/kernel/perf_cpum_cf.c        |  2 +-
>   arch/s390/kernel/perf_cpum_cf_events.c | 11 +++--------
>   2 files changed, 4 insertions(+), 9 deletions(-)
>
Applied to noble:linux, jammy:linux master-next branches. Thanks!