Re: [kvm-unit-tests PATCH v3 1/3] s390x: Test TEID values in storage key test

[Claudio Imbrenda <imbrenda@linux.ibm.com>]

On Wed, 08 Jun 2022 19:03:23 +0200
Janis Schoetterl-Glausch <scgl@linux.ibm.com> wrote:

[...]

> > > +		break;
> > > +	case SOP_ENHANCED_2:
> > > +		switch (teid_esop2_prot_code(teid)) {
> > > +		case PROT_KEY:
> > > +			access_code = teid.acc_exc_f_s;  
> > 
> > is the f/s feature guaranteed to be present when we have esop2?  
> 
> That's how I understand it. For esop1 the PoP explicitly states that
> the facility is a prerequisite, for esop2 it doesn't.
> > 
> > can the f/s feature be present with esop1 or basic sop?  
> 
> esop1: yes, basic: no.
> The way I read it, in the case of esop1 the bits are only meaningful
> for DAT and access list exceptions, i.e. when the TEID is not
> unpredictable.

I see, makes sense

maybe add a comment :)

> >   
> > > +
> > > +			switch (access_code) {
> > > +			case 0:
> > > +				report_pass("valid access code");
> > > +				break;
> > > +			case 1:
> > > +			case 2:
> > > +				report((access & access_code) && (prot & access_code),
> > > +				       "valid access code");
> > > +				break;
> > > +			case 3:
> > > +				/*
> > > +				 * This is incorrect in that reserved values
> > > +				 * should be ignored, but kvm should not return
> > > +				 * a reserved value and having a test for that
> > > +				 * is more valuable.
> > > +				 */
> > > +				report_fail("valid access code");
> > > +				break;
> > > +			}
> > > +			/* fallthrough */
> > > +		case PROT_KEY_LAP:
> > > +			report_pass("valid protection code");
> > > +			break;
> > > +		default:
> > > +			report_fail("valid protection code");
> > > +		}
> > > +		break;
> > > +	}
> > > +	report_prefix_pop();
> > > +}
> > > +  
> 
> [...]