On Wed, 2022-02-23 at 16:39 +0100, Janosch Frank wrote:
> On 2/23/22 14:29, Nico Boehr wrote:
> >
[...]
> >
> > +static void test_stsch(void)
> > +{
> >
[...]
> > + 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.
Will do.
> Do we have the MSS facility?
Not an IO expert, but it seems like it's enabled by QEMU in pc-
bios/s390-ccw/main.c, css_setup(). The comment suggests it's always
there.
> If yes, could we disable it to test the 32-47 == 0x0001 case?
I see ioinst_handle_chsc_sda() in QEMU to enable it. Disabling only
works with a full reset of the CSS (see css_reset()) which can be
triggered from a subsystem_reset(), which basically means we need to
IPL. I think that's not really viable or do you see any other way?
Halil, Pierre, can you confirm?
>
> > +}
> > +
> > +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.
Will add the comment above the function, OK?
> 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.
I already have a test in MSCH which checks for the operand exception.
It's simple enough to extend it to do a STSCH after the MSCH and check
the respective bits is clear. Will be added in v4.
