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.
