Re: [PATCH v6 2/5] selftests: kvm: s390: Add uc_skey VM test case

["Christoph Schlameuss" <schlameuss@linux.ibm.com>]

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.