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