Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

[Cornelia Huck <cohuck@redhat.com>]

On Mon, 9 Apr 2018 12:37:42 +0200
Halil Pasic <pasic@linux.vnet.ibm.com> wrote:

> On 04/09/2018 11:32 AM, Cornelia Huck wrote:
> >> We can kind of (i.e. modulo EECA.28) ensure this in a different fashion I think. How
> >> about proclaiming a 'has ap instructions, but nothing to see here' in the
> >> SIE interpreted flavor (ECA.28 set) the default way of having ap instructions
> >> under KVM. This should be easily accomplished with an all zero CRYCB and eca.28
> >> set. The for the guest to actually get real work done with AP we would
> >> still require some sort of driver to either provide a non-zero matrix by
> >> altering the CRYCB or unsettling ECA.28 and doing the intercepted flavor.
> >>
> >> Please notice, the cpu facility ap would still keep it's semantic
> >> 'has ap instructions' (opposed to 'has ap instructions implemented in
> >> SIE interpreted flavor). And give us all the flexibility.
> >>
> >> Yet implementing what we want to have in absence of a driver would become
> >> much easier (under the assumption that ECA.28 equals EECA.28).
> >>
> >> How about this?  
> > Unfortunately, this is really hard to follow without the AR... let me
> > summarize it to check whether I got the gist of it :)
> > 
> > - If the "ap" cpu feature is specified, set a bit that indicates "hey,
> >   we basically have have AP support" and create the basics, but don't
> >   enable actual SIE handling. This means the guest gets exceptions from
> >   the SIE already and we don't need to emulate them.  
> 
> Kind of. The bit is ECA.28 and tells SIE 'hey SIE shall interpret ap
> instructions for the guest (as specified)'. Then SIE has an SD satellite
> called CRYCB that contains the which ap resources is the guest authorized
> to use. These are the masks. If we set each mask to all zero, we will
> effectively accomplish 'hey,we basically have have AP support but no
> resources at the moment'. So, right, we don't have to emulate that.
> 
> I don't know what do you mean by exceptions. For most legit requests the
> SIE should say APQN invalid, with QCI being a notable exception. But
> of course SIE would inject program exceptions (access, specification,
> and privileged operation) accordingly I guess.

I meant "emulate exceptions"...

> 
> 
> In short, the SIE would do what we are trying to emulate in this patch.

...so yes, exactly that.

> 
> > - Actually enable the missing pieces if a vfio device is created. This
> >   would enable processing by the SIE, and we would not need to do
> >   emulation, either (for most of it, IIRC).  
> 
> Yes. It would actually assign resources to the guest. That would enable
> doing real work with the AP instructions.

Ok.

> 
> > 
> > I may be all wrong, though... can we at least have a translation of
> > ECA.28 and EECA.28 (the "ap is there" bit and the "ap instructions are
> > interpreted" bit?)
> >   
> 
> I think we have a misunderstanding here. I will wait for Tony. Maybe
> he can understand this better or explain in more accessible way.

From what I get from your explanation, this approach sounds like a good
way forward. But let's wait for Tony.