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

[Tony Krowiak]

On 04/09/2018 06:51 AM, Cornelia Huck wrote:
> On Mon, 9 Apr 2018 12:37:42 +0200
> Halil Pasic <address@hidden> 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.

I agree, this solves the problem with specifying installing AP facilities
on the guest (-cpu xxx,ap=on) and not configuring a vfio-ap device
(-device vfio-ap,sysfsdev=$path-to-mediated-device).

To recap:
The realize() function for the vfio-ap device opens the mediated matrix
device file descriptor to set up the communication pathway with the vfio_ap
kernel driver. When the fd is opened, the vfio_ap driver sets ECA.28 for 
the
guest to instruct SIE to interpret AP instructions. The driver also
configures the AP matrix for the guest in its SIE state description. 
Consequently,
if a vfio-ap device is not configured for the guest, but AP facilities are
installed, all AP instructions will be intercepted and routed to QEMU. 
If there
are no interception handlers for the AP instructions, QEMU injects an 
operation
exception into the guest. This results in initialization of the AP bus 
on the
guest to terminate. This patch was intended to circumvent that problem.

With Halil's suggestion, there is no need to provide these handlers. If 
ECA.28
is set for the guest by default when the AP facilities are installed, 
then the AP
instructions will be interpreted and the AP bus will get initialized on the
guest. Since there is no vfio-ap device to provide the AP matrix 
configuration
for the guest, the AP bus will not detect any devices, but that's okay. AP
instructions targeting at an APQN will execute successfully and set a 
response
code in the status block returned from the instruction indicating the
APQN is invalid .... but there will be no exception unless there is truly
an exception condition caused by the execution of the instruction.

>