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). 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? (Are there more possible fcs than 0x3 and whatever the other subfunction was?)
