linux-stable.git/tools/testing/selftests/powerpc, branch v6.8 Linux kernel stable tree selftests/powerpc: Fix fpu_signal failures 2024-03-01T11:15:30+00:00 Michael Ellerman mpe@ellerman.id.au 2024-03-01T10:10:35+00:00 380cb2f4df78433f64847cbc655fad2650e4769c My recent commit e5d00aaac651 ("selftests/powerpc: Check all FPRs in fpu_preempt") inadvertently broke the fpu_signal test. It needs to take into account that fpu_preempt now loads 32 FPRs, so enlarge darray. Also use the newly added randomise_darray() to properly randomise darray. Finally the checking done in signal_fpu_sig() needs to skip checking f30/f31, because they are used as scratch registers in check_all_fprs(), called by preempt_fpu(), and so could hold other values when the signal is taken. Fixes: e5d00aaac651 ("selftests/powerpc: Check all FPRs in fpu_preempt") Reported-by: Spoorthy <spoorthy@linux.ibm.com> Depends-on: 2ba107f6795d ("selftests/powerpc: Generate better bit patterns for FPU tests") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240301101035.1230024-1-mpe@ellerman.id.au 
My recent commit e5d00aaac651 ("selftests/powerpc: Check all FPRs in
fpu_preempt") inadvertently broke the fpu_signal test.

It needs to take into account that fpu_preempt now loads 32 FPRs, so
enlarge darray.

Also use the newly added randomise_darray() to properly randomise darray.

Finally the checking done in signal_fpu_sig() needs to skip checking
f30/f31, because they are used as scratch registers in check_all_fprs(),
called by preempt_fpu(), and so could hold other values when the signal
is taken.

Fixes: e5d00aaac651 ("selftests/powerpc: Check all FPRs in fpu_preempt")
Reported-by: Spoorthy <spoorthy@linux.ibm.com>
Depends-on: 2ba107f6795d ("selftests/powerpc: Generate better bit patterns for FPU tests")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240301101035.1230024-1-mpe@ellerman.id.au
selftests/powerpc/papr_vpd: Check devfd before get_system_loc_code() 2024-02-05T11:47:31+00:00 R Nageswara Sastry rnsastry@linux.ibm.com 2024-01-31T13:08:59+00:00 f09696279b5dd1770a3de2e062f1c5d1449213ff Calling get_system_loc_code before checking devfd and errno fails the test when the device is not available, the expected behaviour is a SKIP. Change the order of 'SKIP_IF_MSG' to correctly SKIP when the /dev/ papr-vpd device is not available. Test output before: Test FAILED on line 271 Test output after: [SKIP] Test skipped on line 266: /dev/papr-vpd not present Signed-off-by: R Nageswara Sastry <rnsastry@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240131130859.14968-1-rnsastry@linux.ibm.com 
Calling get_system_loc_code before checking devfd and errno fails the test
when the device is not available, the expected behaviour is a SKIP.

Change the order of 'SKIP_IF_MSG' to correctly SKIP when the /dev/
papr-vpd device is not available.

Test output before:
  Test FAILED on line 271

Test output after:
  [SKIP] Test skipped on line 266: /dev/papr-vpd not present

Signed-off-by: R Nageswara Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240131130859.14968-1-rnsastry@linux.ibm.com
selftests/powerpc: Fix spelling mistake "EACCESS" -> "EACCES" 2023-12-21T11:13:55+00:00 Colin Ian King colin.i.king@gmail.com 2023-12-15T11:24:56+00:00 ba5b952ad5f52e58c0f288b9d5427ad734600568 There is a spelling mistake of the EACCES error name, fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231215112456.13554-1-colin.i.king@gmail.com 
There is a spelling mistake of the EACCES error name, fix it.

Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231215112456.13554-1-colin.i.king@gmail.com
powerpc/selftests: Add test for papr-sysparm 2023-12-13T10:38:21+00:00 Nathan Lynch nathanl@linux.ibm.com 2023-12-12T17:02:00+00:00 76b2ec3faeaa0c8d84705acd64ac0e5a307ce9c2 Consistently testing system parameter access is a bit difficult by nature -- the set of parameters available depends on the model and system configuration, and updating a parameter should be considered a destructive operation reserved for the admin. So we validate some of the error paths and retrieve the SPLPAR characteristics string, but not much else. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-13-e9eafd0c8c6c@linux.ibm.com 
Consistently testing system parameter access is a bit difficult by
nature -- the set of parameters available depends on the model and
system configuration, and updating a parameter should be considered a
destructive operation reserved for the admin.

So we validate some of the error paths and retrieve the SPLPAR
characteristics string, but not much else.

Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-13-e9eafd0c8c6c@linux.ibm.com
powerpc/selftests: Add test for papr-vpd 2023-12-13T10:38:21+00:00 Nathan Lynch nathanl@linux.ibm.com 2023-12-12T17:01:59+00:00 9118c5d32bddb5f75bc4f9f31218e70317702502 Add selftests for /dev/papr-vpd, exercising the common expected use cases: * Retrieve all VPD by passing an empty location code. * Retrieve the "system VPD" by passing a location code derived from DT root node properties, as done by the vpdupdate command. The tests also verify that certain intended properties of the driver hold: * Passing an unterminated location code to PAPR_VPD_CREATE_HANDLE gets EINVAL. * Passing a NULL location code pointer to PAPR_VPD_CREATE_HANDLE gets EFAULT. * Closing the device node without first issuing a PAPR_VPD_CREATE_HANDLE command to it succeeds. * Releasing a handle without first consuming any data from it succeeds. * Re-reading the contents of a handle returns the same data as the first time. Some minimal validation of the returned data is performed. The tests are skipped on systems where the papr-vpd driver does not initialize, making this useful only on PowerVM LPARs at this point. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-12-e9eafd0c8c6c@linux.ibm.com 
Add selftests for /dev/papr-vpd, exercising the common expected use
cases:

* Retrieve all VPD by passing an empty location code.
* Retrieve the "system VPD" by passing a location code derived from DT
  root node properties, as done by the vpdupdate command.

The tests also verify that certain intended properties of the driver
hold:

* Passing an unterminated location code to PAPR_VPD_CREATE_HANDLE gets
  EINVAL.
* Passing a NULL location code pointer to PAPR_VPD_CREATE_HANDLE gets
  EFAULT.
* Closing the device node without first issuing a
  PAPR_VPD_CREATE_HANDLE command to it succeeds.
* Releasing a handle without first consuming any data from it
  succeeds.
* Re-reading the contents of a handle returns the same data as the
  first time.

Some minimal validation of the returned data is performed.

The tests are skipped on systems where the papr-vpd driver does not
initialize, making this useful only on PowerVM LPARs at this point.

Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231212-papr-sys_rtas-vs-lockdown-v6-12-e9eafd0c8c6c@linux.ibm.com
selftests/powerpc: Check all FPRs in fpu_syscall test 2023-12-13T02:29:09+00:00 Michael Ellerman mpe@ellerman.id.au 2023-11-28T13:27:48+00:00 1bdf22580b794a498b17617bcd7ae417d6b78444 There is a selftest that checks if FPRs are corrupted across a fork, aka clone. It was added as part of the series that optimised the clone path to save the parent's FP state without "giving up" (turning off FP). See commit 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up"). The test encodes the assumption that FPRs 0-13 are volatile across the syscall, by only checking the volatile FPRs are not changed by the fork. There was also a comment in the fpu_preempt test alluding to that: The check_fpu function in asm only checks the non volatile registers as it is reused from the syscall test It is true that the function call ABI treats f0-f13 as volatile, however the syscall ABI has since been documented as *not* treating those registers as volatile. See commit 7b8845a2a2ec ("powerpc/64: Document the syscall ABI"). So change the test to check all FPRs are not corrupted by the syscall. Note that this currently fails, because save_fpu() etc. do not restore f0/vsr0. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231128132748.1990179-5-mpe@ellerman.id.au 
There is a selftest that checks if FPRs are corrupted across a fork, aka
clone. It was added as part of the series that optimised the clone path
to save the parent's FP state without "giving up" (turning off FP).

See commit 8792468da5e1 ("powerpc: Add the ability to save FPU without
giving it up").

The test encodes the assumption that FPRs 0-13 are volatile across the
syscall, by only checking the volatile FPRs are not changed by the fork.
There was also a comment in the fpu_preempt test alluding to that:

  The check_fpu function in asm only checks the non volatile registers
  as it is reused from the syscall test

It is true that the function call ABI treats f0-f13 as volatile,
however the syscall ABI has since been documented as *not* treating those
registers as volatile. See commit 7b8845a2a2ec ("powerpc/64: Document
the syscall ABI").

So change the test to check all FPRs are not corrupted by the syscall.
Note that this currently fails, because save_fpu() etc. do not restore
f0/vsr0.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231128132748.1990179-5-mpe@ellerman.id.au
selftests/powerpc: Run fpu_preempt test for 60 seconds 2023-12-13T02:29:09+00:00 Michael Ellerman mpe@ellerman.id.au 2023-11-28T13:27:47+00:00 60d2c3af9a0c04dc2d34a62e9f5e7033b40dfed8 The FPU preempt test only runs for 20 seconds, which is not particularly long. Run it for 60 seconds to increase the chance of detecting corruption. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231128132748.1990179-4-mpe@ellerman.id.au 
The FPU preempt test only runs for 20 seconds, which is not particularly
long. Run it for 60 seconds to increase the chance of detecting
corruption.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231128132748.1990179-4-mpe@ellerman.id.au
selftests/powerpc: Generate better bit patterns for FPU tests 2023-12-13T02:29:08+00:00 Michael Ellerman mpe@ellerman.id.au 2023-11-28T13:27:46+00:00 2ba107f6795d780bb54b85040a9b2c6a60fccb15 The fpu_preempt test randomly initialises an array of doubles to try and detect FPU register corruption. However the values it generates do not occupy the full range of values possible in the 64-bit double, meaning some partial register corruption could go undetected. Without getting too carried away, add some better initialisation to generate values that occupy more bits. Sample values before: f0 902677510 (raw 0x41cae6e203000000) f1 325217596 (raw 0x41b3626d3c000000) f2 1856578300 (raw 0x41dbaa48bf000000) f3 1247189984 (raw 0x41d295a6f8000000) And after: f0 1.1078153481413311e-09 (raw 0x3e13083932805cc2) f1 1.0576648474801922e+17 (raw 0x43777c20eb88c261) f2 -6.6245033413594075e-10 (raw 0xbe06c2f989facae9) f3 3.0085988827156291e+18 (raw 0x43c4e0585f2df37b) Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231128132748.1990179-3-mpe@ellerman.id.au 
The fpu_preempt test randomly initialises an array of doubles to try and
detect FPU register corruption.

However the values it generates do not occupy the full range of values
possible in the 64-bit double, meaning some partial register corruption
could go undetected.

Without getting too carried away, add some better initialisation to
generate values that occupy more bits.

Sample values before:

  f0             902677510               (raw 0x41cae6e203000000)
  f1             325217596               (raw 0x41b3626d3c000000)
  f2             1856578300              (raw 0x41dbaa48bf000000)
  f3             1247189984              (raw 0x41d295a6f8000000)

And after:

  f0             1.1078153481413311e-09  (raw 0x3e13083932805cc2)
  f1             1.0576648474801922e+17  (raw 0x43777c20eb88c261)
  f2             -6.6245033413594075e-10 (raw 0xbe06c2f989facae9)
  f3             3.0085988827156291e+18  (raw 0x43c4e0585f2df37b)

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231128132748.1990179-3-mpe@ellerman.id.au
selftests/powerpc: Check all FPRs in fpu_preempt 2023-12-13T02:29:08+00:00 Michael Ellerman mpe@ellerman.id.au 2023-11-28T13:27:45+00:00 e5d00aaac651a69b8016d355123438387bfd37be There's a selftest that checks FPRs aren't corrupted by preemption, or just process scheduling. However it only checks the non-volatile FPRs, meaning corruption of the volatile FPRs could go undetected. The check_fpu function it calls is used by several other tests, so for now add a new routine to check all the FPRs. Increase the size of the array of FPRs to 32, and initialise them all with random values. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231128132748.1990179-2-mpe@ellerman.id.au 
There's a selftest that checks FPRs aren't corrupted by preemption, or
just process scheduling. However it only checks the non-volatile FPRs,
meaning corruption of the volatile FPRs could go undetected.

The check_fpu function it calls is used by several other tests, so for
now add a new routine to check all the FPRs. Increase the size of the
array of FPRs to 32, and initialise them all with random values.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231128132748.1990179-2-mpe@ellerman.id.au
selftests/powerpc: Fix error handling in FPU/VMX preemption tests 2023-12-13T02:29:08+00:00 Michael Ellerman mpe@ellerman.id.au 2023-11-28T13:27:44+00:00 9dbd5927408c4a0707de73ae9dd9306b184e8fee The FPU & VMX preemption tests do not check for errors returned by the low-level asm routines, preempt_fpu() / preempt_vsx() respectively. That means any register corruption detected by the asm routines does not result in a test failure. Fix it by returning the return value of the asm routines from the pthread child routines. Fixes: e5ab8be68e44 ("selftests/powerpc: Test preservation of FPU and VMX regs across preemption") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231128132748.1990179-1-mpe@ellerman.id.au 
The FPU & VMX preemption tests do not check for errors returned by the
low-level asm routines, preempt_fpu() / preempt_vsx() respectively.
That means any register corruption detected by the asm routines does not
result in a test failure.

Fix it by returning the return value of the asm routines from the
pthread child routines.

Fixes: e5ab8be68e44 ("selftests/powerpc: Test preservation of FPU and VMX regs across preemption")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231128132748.1990179-1-mpe@ellerman.id.au