[kvm-unit-tests PATCH] s390x: sie: Test whether the epoch extension field is working as expected

[kvm-unit-tests PATCH] s390x: sie: Test whether the epoch extension field is working as expected

[Thomas Huth]

We recently discovered a bug with the time management in nested scenarios
which got fixed by kernel commit "KVM: s390: vsie: Fix the initialization
of the epoch extension (epdx) field". This adds a simple test for this
bug so that it is easier to decide whether the host kernel of a machine
has already been fixed or not.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 s390x/sie.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/s390x/sie.c b/s390x/sie.c
index 87575b29..7ec4b030 100644
--- a/s390x/sie.c
+++ b/s390x/sie.c
@@ -58,6 +58,33 @@ static void test_diags(void)
 	}
 }
 
+static void test_epoch_ext(void)
+{
+	u32 instr[] = {
+		0xb2780000,	/* STCKE 0 */
+		0x83020044	/* DIAG 0x44 to intercept */
+	};
+
+	if (!test_facility(139)) {
+		report_skip("epdx: Multiple Epoch Facility is not available");
+		return;
+	}
+
+	guest[0] = 0x00;
+	memcpy(guest_instr, instr, sizeof(instr));
+
+	vm.sblk->gpsw.addr = PAGE_SIZE * 2;
+	vm.sblk->gpsw.mask = PSW_MASK_64;
+
+	vm.sblk->ecd |= ECD_MEF;
+	vm.sblk->epdx = 0x47;	/* Setting the epoch extension here ... */
+
+	sie(&vm);
+
+	/* ... should result in the same epoch extension here: */
+	report(guest[0] == 0x47, "epdx: different epoch is visible in the guest");
+}
+
 static void setup_guest(void)
 {
 	setup_vm();
@@ -80,6 +107,7 @@ int main(void)
 
 	setup_guest();
 	test_diags();
+	test_epoch_ext();
 	sie_guest_destroy(&vm);
 
 done:
-- 
2.31.1

Re: [kvm-unit-tests PATCH] s390x: sie: Test whether the epoch extension field is working as expected

[Claudio Imbrenda]

On Wed,  7 Dec 2022 14:31:18 +0100
Thomas Huth <thuth@redhat.com> wrote:

> We recently discovered a bug with the time management in nested scenarios
> which got fixed by kernel commit "KVM: s390: vsie: Fix the initialization
> of the epoch extension (epdx) field". This adds a simple test for this
> bug so that it is easier to decide whether the host kernel of a machine

s/decide/determine/

> has already been fixed or not.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  s390x/sie.c | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/s390x/sie.c b/s390x/sie.c
> index 87575b29..7ec4b030 100644
> --- a/s390x/sie.c
> +++ b/s390x/sie.c
> @@ -58,6 +58,33 @@ static void test_diags(void)
>  	}
>  }
>  
> +static void test_epoch_ext(void)
> +{
> +	u32 instr[] = {
> +		0xb2780000,	/* STCKE 0 */
> +		0x83020044	/* DIAG 0x44 to intercept */

I'm conflicted about this. one one hand, it should be 0x83000044, but
on the other hand it does not matter at all, and the other testcase
also has the spurious 2 in the middle (to check things we are not
checking here)

> +	};
> +
> +	if (!test_facility(139)) {
> +		report_skip("epdx: Multiple Epoch Facility is not available");
> +		return;
> +	}
> +
> +	guest[0] = 0x00;
> +	memcpy(guest_instr, instr, sizeof(instr));
> +
> +	vm.sblk->gpsw.addr = PAGE_SIZE * 2;
> +	vm.sblk->gpsw.mask = PSW_MASK_64;
> +
> +	vm.sblk->ecd |= ECD_MEF;
> +	vm.sblk->epdx = 0x47;	/* Setting the epoch extension here ... */
> +
> +	sie(&vm);
> +
> +	/* ... should result in the same epoch extension here: */
> +	report(guest[0] == 0x47, "epdx: different epoch is visible in the guest");
> +}
> +
>  static void setup_guest(void)
>  {
>  	setup_vm();
> @@ -80,6 +107,7 @@ int main(void)
>  
>  	setup_guest();
>  	test_diags();
> +	test_epoch_ext();
>  	sie_guest_destroy(&vm);
>  
>  done:

Re: [kvm-unit-tests PATCH] s390x: sie: Test whether the epoch extension field is working as expected

[Thomas Huth]

On 07/12/2022 15.59, Claudio Imbrenda wrote:
> On Wed,  7 Dec 2022 14:31:18 +0100
> Thomas Huth <thuth@redhat.com> wrote:
> 
>> We recently discovered a bug with the time management in nested scenarios
>> which got fixed by kernel commit "KVM: s390: vsie: Fix the initialization
>> of the epoch extension (epdx) field". This adds a simple test for this
>> bug so that it is easier to decide whether the host kernel of a machine
> 
> s/decide/determine/
> 
>> has already been fixed or not.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>   s390x/sie.c | 28 ++++++++++++++++++++++++++++
>>   1 file changed, 28 insertions(+)
>>
>> diff --git a/s390x/sie.c b/s390x/sie.c
>> index 87575b29..7ec4b030 100644
>> --- a/s390x/sie.c
>> +++ b/s390x/sie.c
>> @@ -58,6 +58,33 @@ static void test_diags(void)
>>   	}
>>   }
>>   
>> +static void test_epoch_ext(void)
>> +{
>> +	u32 instr[] = {
>> +		0xb2780000,	/* STCKE 0 */
>> +		0x83020044	/* DIAG 0x44 to intercept */
> 
> I'm conflicted about this. one one hand, it should be 0x83000044, but
> on the other hand it does not matter at all, and the other testcase
> also has the spurious 2 in the middle (to check things we are not
> checking here)

D'oh, I simply copy-n-pasted that value from the other test ... well, it 
shouldn't really matter as long as the instruction just gets intercepted. 
OTOH, it's nicer if we make it at least clean here in this new code. I'll 
send a v2 without this "2" in between.

  Thomas