From: Pierre Morel <pmorel@linux.ibm.com>
To: Janosch Frank <frankja@linux.ibm.com>,
Nico Boehr <nrb@linux.ibm.com>,
kvm@vger.kernel.org, linux-s390@vger.kernel.org
Cc: imbrenda@linux.ibm.com, Halil Pasic <pasic@linux.ibm.com>,
thuth@redhat.com, david@redhat.com
Subject: Re: [kvm-unit-tests PATCH v3 6/8] s390x: Add more tests for STSCH
Date: Thu, 24 Feb 2022 11:27:02 +0100 [thread overview]
Message-ID: <06404959-0357-e33d-6114-0484d81578c9@linux.ibm.com> (raw)
In-Reply-To: <04daca6a-5863-d205-ea98-096163a2296a@linux.ibm.com>
On 2/23/22 16:39, Janosch Frank wrote:
> On 2/23/22 14:29, Nico Boehr wrote:
>> css_lib extensively uses STSCH, but two more cases deserve their own
>> tests:
>>
>> - unaligned address for SCHIB. We check for misalignment by 1 and 2
>> bytes.
>> - channel not operational
>> - bit 47 in SID not set
>> - bit 5 of PMCW flags.
>> As per the principles of operation, bit 5 of the PMCW flags shall be
>> ignored by msch and always stored as zero by stsch.
>>
>> Older QEMU versions require this bit to always be zero on msch,
>> which is why this test may fail. A fix is available in QEMU master
>> commit 2df59b73e086 ("s390x/css: fix PMCW invalid mask"). >
>> Here's the QEMU PMCW invalid mask fix:
>> https://lists.nongnu.org/archive/html/qemu-s390x/2021-12/msg00100.html
>>
>> Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
>> ---
>> s390x/css.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 74 insertions(+)
>>
>> diff --git a/s390x/css.c b/s390x/css.c
>> index a90a0cd64e2b..021eb12573c0 100644
>> --- a/s390x/css.c
>> +++ b/s390x/css.c
>> @@ -496,6 +496,78 @@ static void test_ssch(void)
>> report_prefix_pop();
>> }
>> +static void test_stsch(void)
>> +{
>> + const int align_to = 4;
>> + struct schib schib;
>> + int cc;
>> +
>> + if (!test_device_sid) {
>> + report_skip("No device");
>> + return;
>> + }
>> +
>> + report_prefix_push("Unaligned");
>> + for (int i = 1; i < align_to; i *= 2) {
>> + report_prefix_pushf("%d", i);
>> +
>> + expect_pgm_int();
>> + stsch(test_device_sid, (struct schib *)(alignment_test_page +
>> i));
>> + check_pgm_int_code(PGM_INT_CODE_SPECIFICATION);
>> +
>> + report_prefix_pop();
>> + }
>> + report_prefix_pop();
>> +
>> + report_prefix_push("Invalid subchannel number");
>> + cc = stsch(0x0001ffff, &schib);
>> + report(cc == 3, "Channel not operational");
>> + report_prefix_pop();
>> +
>> + report_prefix_push("Bit 47 in SID is zero");
>> + expect_pgm_int();
>> + stsch(0x0000ffff, &schib);
>> + check_pgm_int_code(PGM_INT_CODE_OPERAND);
>> + report_prefix_pop();
>
> Add a comment:
> No matter if the multiple-subchannel-set facility is installed or not,
> bit 47 always needs to be 1.
>
> Do we have the MSS facility?
yes
> If yes, could we disable it to test the 32-47 == 0x0001 case?
AFAIK it is not enabled in the KVM unit tests
We are able to enable it, it could be done with CHSC tests.
>
>> +}
>> +
>> +static void test_pmcw_bit5(void)
>> +{
>> + int cc;
>> + uint16_t old_pmcw_flags;
>
> I need a comment here for further reference since that behavior is
> documented at the description of the schib and not where STSCH is
> described:
> According to architecture MSCH does ignore bit 5 of the second word but
> STSCH will store bit 5 as zero.
>
>
> We could check if bits 0,1 and 6,7 are also zero but I'm not sure if
> that's interesting since MSCH does not ignore those bits and should
> result in an operand exception when trying to set them.
>
> @Halil, @Pierre: Any opinions?
Yes we should check this.
We often do STSCH/MSCH in a row so I think it is interesting to check it.
>
>> +
>> + cc = stsch(test_device_sid, &schib);
>> + if (cc) {
>> + report_fail("stsch: sch %08x failed with cc=%d",
>> test_device_sid, cc);
>> + return;
>> + }
>> + old_pmcw_flags = schib.pmcw.flags;
>> +
>> + report_prefix_push("Bit 5 set");
>> +
>> + schib.pmcw.flags = old_pmcw_flags | BIT(15 - 5);
>> + cc = msch(test_device_sid, &schib);
>> + report(!cc, "MSCH cc == 0");
>> +
>> + cc = stsch(test_device_sid, &schib);
>> + report(!cc, "STSCH cc == 0");
>> + report(!(schib.pmcw.flags & BIT(15 - 5)), "STSCH PMCW Bit 5 is
>> clear");
>> +
>> + report_prefix_pop();
>> +
>> + report_prefix_push("Bit 5 clear");
>> +
>> + schib.pmcw.flags = old_pmcw_flags & ~BIT(15 - 5);
>> + cc = msch(test_device_sid, &schib);
>> + report(!cc, "MSCH cc == 0");
>> +
>> + cc = stsch(test_device_sid, &schib);
>> + report(!cc, "STSCH cc == 0");
>> + report(!(schib.pmcw.flags & BIT(15 - 5)), "STSCH PMCW Bit 5 is
>> clear");
>> +
>> + report_prefix_pop();
>> +}
>> +
>> static struct {
>> const char *name;
>> void (*func)(void);
>> @@ -511,6 +583,8 @@ static struct {
>> { "msch", test_msch },
>> { "stcrw", test_stcrw },
>> { "ssch", test_ssch },
>> + { "stsch", test_stsch },
>> + { "pmcw bit 5 ignored", test_pmcw_bit5 },
>> { NULL, NULL }
>> };
>
--
Pierre Morel
IBM Lab Boeblingen
next prev parent reply other threads:[~2022-02-24 10:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 13:29 [kvm-unit-tests PATCH v3 0/8] s390x: Extend instruction interception tests Nico Boehr
2022-02-23 13:29 ` [kvm-unit-tests PATCH v3 1/8] s390x: Add more tests for MSCH Nico Boehr
2022-02-23 13:29 ` [kvm-unit-tests PATCH v3 2/8] s390x: Add test for PFMF low-address protection Nico Boehr
2022-02-23 13:29 ` [kvm-unit-tests PATCH v3 3/8] s390x: Add sck tests Nico Boehr
2022-02-23 13:29 ` [kvm-unit-tests PATCH v3 4/8] s390x: Add tests for STCRW Nico Boehr
2022-02-23 13:29 ` [kvm-unit-tests PATCH v3 5/8] s390x: Add more tests for SSCH Nico Boehr
2022-02-23 13:29 ` [kvm-unit-tests PATCH v3 6/8] s390x: Add more tests for STSCH Nico Boehr
2022-02-23 15:16 ` Claudio Imbrenda
2022-02-23 15:39 ` Janosch Frank
2022-02-23 17:33 ` Nico Boehr
2022-02-24 0:13 ` Halil Pasic
2022-02-24 10:27 ` Pierre Morel [this message]
2022-02-24 10:28 ` Pierre Morel
2022-02-24 14:08 ` Halil Pasic
2022-02-23 13:29 ` [kvm-unit-tests PATCH v3 7/8] s390x: Add tests for TSCH Nico Boehr
2022-02-23 13:29 ` [kvm-unit-tests PATCH v3 8/8] s390x: Add EPSW test Nico Boehr
2022-02-23 15:14 ` [kvm-unit-tests PATCH v3 0/8] s390x: Extend instruction interception tests Claudio Imbrenda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=06404959-0357-e33d-6114-0484d81578c9@linux.ibm.com \
--to=pmorel@linux.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox