On 2020/4/24 6:39 PM, Mark Rutland wrote:
On Fri, Apr 24, 2020 at 03:50:22AM +0100, Jianyong Wu wrote:On 2020/4/21 5:57 PM, Mark Rutland wrote:On Tue, Apr 21, 2020 at 11:23:00AM +0800, Jianyong Wu wrote:diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c index 550dfa3e53cd..a5309c28d4dc 100644 --- a/virt/kvm/arm/hypercalls.c +++ b/virt/kvm/arm/hypercalls.c@@ -62,6 +66,44 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu) if (gpa != GPA_INVALID) val = gpa; break; +/* + * This serves virtual kvm_ptp. + * Four values will be passed back. + * reg0 stores high 32-bit host ktime; + * reg1 stores low 32-bit host ktime; + * reg2 stores high 32-bit difference of host cycles and cntvoff; + * reg3 stores low 32-bit difference of host cycles and cntvoff. + */ +case ARM_SMCCC_HYP_KVM_PTP_FUNC_ID:Shouldn't the host opt-in to providing this to the guest, as with other features?er, do you mean that "ARM_SMCCC_HV_PV_TIME_XXX" as "opt-in"? if so, I think this kvm_ptp doesn't need a buddy. the driver in guest will call this service in a definite way.I mean that when creating the VM, userspace should be able to choose whether the PTP service is provided to the guest. The host shouldn't always provide it as there may be cases where doing so is undesireable.
I think I have implemented in patch 9/9 that userspace can get the info that if the host offers the kvm_ptp service. But for now, the host kernel will always offer the kvm_ptp capability in the current implementation. I think x86 follow the same behavior (see [1]). so I have not considered when and how to disable this kvm_ptp service in host. Do you think we should offer this opt-in?
_______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
