On Wed, 08 Jun 2022 19:03:23 +0200
Janis Schoetterl-Glausch <scgl@xxxxxxxxxxxxx> 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();
> > > +}
> > > +
>
> [...]
