On 28/02/2019 12:03, Christian Borntraeger 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.
May be return a privileged operation exception if issued from guest's
program state, but generally I agree with the idea of handling all PQAP
functions here.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
