Re: [kvm-unit-tests PATCH 3/9] s390x: uv-host: Fence a destroy cpu test on z15

Janosch Frank
2021-09-28T11:21:24Z

On 9/27/21 17:26, Thomas Huth wrote:
> On 22/09/2021 09.18, Janosch Frank wrote:
>> Firmware will not give us the expected return code on z15 so let's
>> fence it for the z15 machine generation.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> ---
>> lib/s390x/asm/arch_def.h | 14 ++++++++++++++
>> s390x/uv-host.c | 11 +++++++----
>> 2 files changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/s390x/asm/arch_def.h b/lib/s390x/asm/arch_def.h
>> index aa80d840..c8d2722a 100644
>> --- a/lib/s390x/asm/arch_def.h
>> +++ b/lib/s390x/asm/arch_def.h
>> @@ -219,6 +219,20 @@ static inline unsigned short stap(void)
>> return cpu_address;
>> }
>>
>> +#define MACHINE_Z15A 0x8561
>> +#define MACHINE_Z15B 0x8562
>> +
>> +static inline uint16_t get_machine_id(void)
>> +{
>> + uint64_t cpuid;
>> +
>> + asm volatile("stidp %0" : "=Q" (cpuid));
>> + cpuid = cpuid >> 16;
>> + cpuid &= 0xffff;
>> +
>> + return cpuid;
>> +}
>> +
>> static inline int tprot(unsigned long addr)
>> {
>> int cc;
>> diff --git a/s390x/uv-host.c b/s390x/uv-host.c
>> index 66a11160..5e351120 100644
>> --- a/s390x/uv-host.c
>> +++ b/s390x/uv-host.c
>> @@ -111,6 +111,7 @@ static void test_config_destroy(void)
>> static void test_cpu_destroy(void)
>> {
>> int rc;
>> + uint16_t machineid = get_machine_id();
>> struct uv_cb_nodata uvcb = {
>> .header.len = sizeof(uvcb),
>> .header.cmd = UVC_CMD_DESTROY_SEC_CPU,
>> @@ -125,10 +126,12 @@ static void test_cpu_destroy(void)
>> "hdr invalid length");
>> uvcb.header.len += 8;
>>
>> - uvcb.handle += 1;
>> - rc = uv_call(0, (uint64_t)&uvcb);
>> - report(rc == 1 && uvcb.header.rc == UVC_RC_INV_CHANDLE, "invalid handle");
>> - uvcb.handle -= 1;
>> + if (machineid != MACHINE_Z15A && machineid != MACHINE_Z15B) {
>> + uvcb.handle += 1;
>> + rc = uv_call(0, (uint64_t)&uvcb);
>> + report(rc == 1 && uvcb.header.rc == UVC_RC_INV_CHANDLE, "invalid handle");
>> + uvcb.handle -= 1;
>> + }
>
> So this is a bug in the firmware? Any chance that it will still get fixed
> for the z15? If so, would it make sense to turn this into a report_xfail()
> instead?
>
> Thomas
>

No, a xfail will not help here.