Re: [PATCH v4 1/7] s390: ap: kvm: add PQAP interception for AQIC

[Pierre Morel]

On 28/02/2019 12:22, Cornelia Huck wrote:
> On Thu, 28 Feb 2019 12:03:38 +0100
> Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:
>
> > On 28.02.2019 10:42, Christian Borntraeger wrote:
> > [...]
> > > > Okay, let's go back to the genesis of this discussion; namely, my
> > > > suggestion about moving the fc == 0x03 check into the hook code. If
> > > > the vfio_ap module is not loaded, there will be no hook code. In that
> > > > case, the check for the hook will fail and ultimately response code
> > > > 0x01 will be set in the status word (which may not be the right thing
> > > > to do?). You have not stated a single good reason for keeping this
> > > > check, but I'm done with this silly argument. It certainly doesn't
> > > > hurt anything.
> > >
> > > The instruction handler must handle the basic checks for the
> > > instruction itself as outlined above.
> > >
> > > Do we want to allow QEMU to fully emulate everything (the  ECA_APIE case being off)?
> > > The we should pass along everything to QEMU, but this is already done with the
> > > ECA_APIE check, correct?
> > >
> > > Do we agree that when we are beyond the ECA_APIE check, that we do not emulate
> > > in QEMU and we have enabled the AP instructions interpretion?
> > > If yes then this has some implication:
> > >
> > > 1. ECA is on and we should only get PQAP interception for specific FC (namely 3).
> > > 2. What we certainly should check is the facility bit of the guest (65) and reject fc==3
> > > right away with a specification exception. I do not want the hook to mess with
> > > the kvm cpu model. @Pierre would be good to actually check test_kvm_facility(vcpu->kvm, 65))
> > > 3. What shall we do when fc == 0x3? We can certainly do the check here OR in the
> > > hook. As long as we have only fc==3 this does not matter.
> > >
> > > Correct?
> >
> > Thinking more about that, I think we should inject a specification exception for all
> > unknown FCc != 0x3. That would also qualify for keeping it in the instruction handler.
>
> So, to summarize, the function should do:
> - Is userspace supposed to emulate everything (!ECA_APIE)? Return
>    -EOPNOTSUPP to hand control to it.
> - We are now interpreting the instruction in KVM. Do common checks
>    (PSTATE etc.) and inject exceptions, if needed.
> - Now look at the fc; if there's a handler for it, call that; if not
>    (case does not attempt to call a specific handler, or no handler
>    registered), inject a specification exception. (Do we want pre-checks
>    like for facility 65 here, or in the handler?)
>
> That response code 0x01 thingy probably needs to go into the specific
> handler function, if anywhere (don't know the semantics, sorry).

What do you mean with specific handler function?

If you mean a switch around the FC with static function's call, I agree, 
if you mean a jump into a hook I do not agree.


> Question: Will the handlers for the individual fcs need to generate
> different exceptions on their own? I.e., do they need to do injections
> themselves, or should the calling function possibly inject an exception
> on error?

There are some specificities.

> (Are there more possible fcs than 0x3 and whatever the other
> subfunction was?)

Yes, at least 5 different FC are implemented in the Linux kernel today 
AFAIK.

Regards,
Pierre

--
Pierre Morel
Linux/KVM/QEMU in BÃblingen - Germany