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

From: Pierre Morel
Date: Fri Mar 01 2019 - 10:32:42 EST


On 01/03/2019 13:36, Cornelia Huck wrote:
On Fri, 1 Mar 2019 13:05:54 +0100
Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:

On 01.03.2019 13:03, Pierre Morel wrote:
On 28/02/2019 15:14, Pierre Morel wrote:
On 28/02/2019 14:52, Cornelia Huck wrote:
On Thu, 28 Feb 2019 14:16:09 +0100
Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote:
On 28/02/2019 12:22, Cornelia Huck wrote:
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.

Ah, ok; so each case (that we want to handle) should call into a
subhandler that does
{
ÂÂÂÂ(... check things like facilities ...)
ÂÂÂÂif (!specific_hook)
ÂÂÂÂÂÂÂ inject_specif_excp_and_return();
ÂÂÂÂret = specific_hook();
ÂÂÂÂif (ret)
ÂÂÂÂÂÂÂ set_resp_code_0x01(); // or in specific_hook()?
}

?

Yes something in this direction.

Sorry, after reflection, no, we do not want to change the previous behavior so we only handle the AQIC case.

I think what you wanted to say is the following:
Today (without the patch set) we will answer PQAP with an exception.
With this patch set we want to handle FC==3, but nothing else. So for anything FC!=3 we
will continue to return an exception?

Correct?

Yes correct.
Thanks for the much preciser explanation.



That sounds reasonable; but I don't see how this conflicts with my
proposal? Just don't introduce a subfunction for fc != 3...


Correct too, it does not conflict, as you said it is just not introduce subfunctions.

Regards,
Pierre


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