[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1875741b-402d-d113-86ff-48adbf782727@redhat.com>
Date: Tue, 25 Feb 2020 16:00:49 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>
Cc: Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 29/61] KVM: x86: Add Kconfig-controlled auditing of
reverse CPUID lookups
On 24/02/20 14:54, Vitaly Kuznetsov wrote:
>> --- a/arch/x86/kvm/cpuid.h
>> +++ b/arch/x86/kvm/cpuid.h
>> @@ -98,6 +98,11 @@ static __always_inline struct cpuid_reg x86_feature_cpuid(unsigned x86_feature)
>> static __always_inline u32 *__cpuid_entry_get_reg(struct kvm_cpuid_entry2 *entry,
>> const struct cpuid_reg *cpuid)
>> {
>> +#ifdef CONFIG_KVM_CPUID_AUDIT
>> + WARN_ON_ONCE(entry->function != cpuid->function);
>> + WARN_ON_ONCE(entry->index != cpuid->index);
>> +#endif
>> +
>> switch (cpuid->reg) {
>> case CPUID_EAX:
>> return &entry->eax;
> Honestly, I was thinking we should BUG_ON() and even in production builds
> but not everyone around is so rebellious I guess, so
BUG_ON is too much, but I agree the cost is so small that unconditional
WARN_ON makes sense.
Paolo
Powered by blists - more mailing lists