Hi Salil,
On 03/11/2022 16:54, Salil Mehta wrote:
Question: We are using HVC conduit for PSCI,
You might be using HVC - its whatever you put in the flags field of the FADT. Don't assume its hardcoded, as for nested-virts virtual-EL2 it needs to be SMC.
do we need a check if hypercall being trapped to userspace is SMC or HVC?
Ideally, yes. If the guest is using something other than the conduit you specified for PSCI, it shouldn't get PSCI back.
File: linux/arch/arm64/kvm/hypercalls.c (your code change) int kvm_hvc_user(struct kvm_vcpu *vcpu) { [...]
run->exit_reason = KVM_EXIT_HYPERCALL; run->hypercall.nr = kvm_vcpu_hvc_get_imm(vcpu); -> this would be referred by userspace code? /* Add the first parameters for fast access. */ [...]
return 0; }
# Userspace Code Excerpt (JPB's June 2021 code reference)
In the userspace, a check similar to below might be required I guess:
/* Under KVM, the PSCI conduit is HVC */
if (imm & KVM_ARM_EXIT_HYPERCALL_SMC) {
XXXX_log_mask("%s: unexpected SMC exit\n", __func__);return 0;}
+/*
- In kvm_run::hypercall::nr, this bit indicates that the call is a SMC. When
- the bit is not set, the call is an HVC.
- */
+#define KVM_ARM_EXIT_HYPERCALL_SMC (1ULL << 63)
I am being lazy but Could you please provide more clarification on the use of 'hypercall.nr' for this check?
Its the immediate as part of the HVC/SMC instruction. PSCI says it should be 0 for PSCI, so anything implementing PSCI should check that. I think HyperV's use of this stuff uses a different immediate - so the register values alone are not enough to prevent collisions.
Thanks,
James