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
