On Tue Oct 15, 2024 at 3:22 PM CEST, Janosch Frank wrote:
> On 10/15/24 10:37 AM, Christoph Schlameuss wrote:
> > Add a test case manipulating s390 storage keys from within the ucontrol
> > VM.
> >
> > Storage key instruction (ISKE, SSKE and RRBE) intercepts and
> > Keyless-subset facility are disabled on first use, where the skeys are
> > setup by KVM in non ucontrol VMs.
> >
>
> [...]
>
> > -/* verify SIEIC exit
> > +/*
> > + * Disable skey intercepts and rewind last instruction
> > + * (KVM would init the skeys here)
> > + */
> > +static void uc_skey_enable(FIXTURE_DATA(uc_kvm) *self)
> > +{
> > + struct kvm_s390_sie_block *sie_block = self->sie_block;
> > + int ilen = insn_length(sie_block->ipa >> 8);
> > + struct kvm_run *run = self->run;
> > +
> > + /* disable KSS */
> > + sie_block->cpuflags &= ~CPUSTAT_KSS;
> > + /* disable skey inst interception */
> > + sie_block->ictl &= ~(ICTL_ISKE | ICTL_SSKE | ICTL_RRBE);
> > +
> > + /* rewind to reexecute intercepted instruction */
> > + run->psw_addr = run->psw_addr - ilen;
>
> There's a very important detail between KSS and the SKEY ICTLs:
> KSS is (mostly) nullifying i.e. the PSW points to the instruction that
> caused the KSS exit.
> ICTL intercepts are suppressing which means the PSW points after the
> instruction and hence we need to rewind the PSW if we want to re-issue
> the instruction.
>
> Re-winding on a KSS intercept makes the guest cpu execute the
> instruction before the intercept producing instruction twice.
Oh, yes. You are right, I did mess that up in my cleanup. I will fix that.
Here it does now only work since the KSS is not intercepted on the second
invocation. But I am with you, it should only be executed once.
