On Thu, Jun 4, 2020 at 11:35 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 05/06/20 07:00, Xiaoyao Li wrote: > > you could do > > > > bool guest_cpuid_aperfmperf = false; > > if (best) > > guest_cpuid_aperfmperf = !!(best->ecx & BIT(0)); > > > > if (guest_cpuid_aperfmerf != guest_has_aperfmperf(vcpu->kvm)) > > return -EINVAL; > > > > > > In fact, I think we can do nothing here. Leave it as what usersapce > > wants just like how KVM treats other CPUID bits. > > The reason to do it like Rongqing did is that it's suggested to take the > output of KVM_GET_SUPPORTED_CPUID and pass it down to KVM_SET_CPUID2. > Unfortunately we have KVM_GET_SUPPORTED_CPUID as a /dev/kvm (not VM) > ioctl, otherwise you could have used guest_has_aperfmperf to affect the > output of KVM_GET_SUPPORTED_CPUID. > > I think it's okay however to keep it simple as you suggest. In this > case however __do_cpuid_func must not return the X86_FEATURE_APERFMPERF bit. > > The guest can instead check for the availability of KVM_CAP_APERFMPERF, > which is already done in Rongqing's patch. > > >> @@ -4930,6 +4939,11 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > >> kvm->arch.exception_payload_enabled = cap->args[0]; > >> r = 0; > >> break; > >> + case KVM_CAP_APERFMPERF: > >> + kvm->arch.aperfmperf_mode = > >> + boot_cpu_has(X86_FEATURE_APERFMPERF) ? cap->args[0] : 0; > > > > Shouldn't check whether cap->args[0] is a valid value? > > Yes, only valid values should be allowed. > > Also, it should fail with -EINVAL if the host does not have > X86_FEATURE_APERFMPERF. Should enabling/disabling this capability be disallowed once vCPUs have been created?
