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

[Thomas Huth <thuth@redhat.com>]

On 28/09/2021 13.21, Janosch Frank wrote:
> 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;

You could skip the masking line since the function returns an uint61_t anyway.

>>> +
>>> +    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.

Ok, fair, then I think the patch is fine:

Acked-by: Thomas Huth <thuth@redhat.com>