On 22/06/2020 09:20, Marc Zyngier wrote:
Hi Andrew, On 2020-06-19 19:46, Andrew Jones wrote:
[...]
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 4fdf30316582..121fb29ac004 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1031,6 +1031,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_PPC_SECURE_GUEST 181 #define KVM_CAP_HALT_POLL 182 #define KVM_CAP_ASYNC_PF_INT 183 +#define KVM_CAP_STEAL_TIME 184 #ifdef KVM_CAP_IRQ_ROUTINGShouldn't you also add the same check of sched_info_on() to the various pvtime attribute handling functions? It feels odd that the capability can say "no", and yet we'd accept userspace messing with the steal time parameters...
My thought was that to some extent the two are separate. KVM_CAP_STEAL_TIME is "we have stolen time _AND_ it returns meaningful numbers", KVM_HAS_DEVICE_ATTR(KVM_ARM_VCPU_PVTIME_IPA) is (unfortunately) "we have the stolen interface, but it might not show how much time is stolen". Restoring a VM on a host with VCPU_PVTIME_IPA but without KVM_CAP_STEAL_TIME is possible just won't provide any stolen time data (the SMC calls will still work and the data format is valid).
Obviously with hindsight I would have done this differently... Steve _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
