On 18/02/2019 23:42, Cornelia Huck wrote:
On Mon, 18 Feb 2019 19:29:10 +0100
Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote:
On 15/02/2019 23:02, Tony Krowiak wrote:
On 2/14/19 8:51 AM, Pierre Morel wrote:
+/*
+ * handle_pqap: Handling pqap interception
+ * @vcpu: the vcpu having issue the pqap instruction
+ *
+ * This callback only handles PQAP/AQIC instruction and
+ * calls a dedicated callback for this instruction if
+ * a driver did register one in the CRYPTO satellite of the
+ * SIE block.
+ *
+ * Do not change the behavior if, return -EOPNOTSUPP if:
+ * - the hook is not used do not change the behavior.
+ * - AP instructions are not available or not available to the guest
+ * - the instruction is not PQAP with function code indicating
+ * AQIC do not change the previous behavior.
+ *
+ * For PQAP/AQIC instruction, verify privilege and specifications
+ *
+ * return the value returned by the callback.
+ */
+static int handle_pqap(struct kvm_vcpu *vcpu)
+{
+ uint8_t fc;
+
+ /* Verify that the hook callback is registered */
+ if (!vcpu->kvm->arch.crypto.pqap_hook)
+ return -EOPNOTSUPP;
+ /* Verify that the AP instruction are available */
+ if (!ap_instructions_available())
+ return -EOPNOTSUPP;
+ /* Verify that the guest is allowed to use AP instructions */
+ if (!(vcpu->arch.sie_block->eca & ECA_APIE))
+ return -EOPNOTSUPP;
+ /* Verify that the function code is AQIC */
+ fc = vcpu->run->s.regs.gprs[0] >> 24;
+ if (fc != 0x03)
+ return -EOPNOTSUPP;
This does not belong here. Function code 3 is one of 7 function codes
that can be sent with the PQAP instruction. This belongs in the PQAP
hook code.
On one hand, effectively I would prefer to put the code in the VFIO
driver code.
On the other hand, doing this would lead to export the code for
test_kvm_facility() and kvm_s390_inject_program_int() from the kvm-s390.h
I choose not to export these functions from the KVM code.
Would like opinion from KVM maintainers?
Looking at this (and without access to the specification...), I think
the check for problem state makes sense in here (if this applies to all
PQAP functions equally, which seems likely). The check for the facility
makes more sense in the handler. You can probably still inject the
specification exception here if you use a clever return code.
If there is no objection on exporting the KVM functions... I can do this.
Another option: Provide a way to register a callback per function code;
this allows you to still do the check here and extend it later for
other function codes (which will probably be indicated by another
facility).
I like this option even better.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
