[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YVXTnheIB6MCKGve@google.com>
Date: Thu, 30 Sep 2021 15:11:26 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org,
syzbot+f3985126b746b3d59c9d@...kaller.appspotmail.com,
Alexander Potapenko <glider@...gle.com>
Subject: Re: [PATCH 2/2] KVM: x86: Manually retrieve CPUID.0x1 when getting
FMS for RESET/INIT
On Thu, Sep 30, 2021, Paolo Bonzini wrote:
> On 30/09/21 00:24, Sean Christopherson wrote:
> > * RESET since KVM emulates RESET before exposing the vCPU to userspace,
> > * i.e. it'simpossible for kvm_cpuid() to find a valid entry on RESET.
> > + * But, go through the motions in case that's ever remedied. Note, the
> > + * index for CPUID.0x1 is not significant, arbitrarily specify '0'.
>
> Just one nit, this comment change is not really needed because almost all
> callers are using '0' for the same reason.
>
> But, perhaps adding kvm_find_cpuid_entry_index and removing the last
> parameter from kvm_find_cpuid_entry would be a good idea.
I like this idea, but only if callers are forced to specify the index when the
index is significant, e.g. add a magic CPUID_INDEX_DONT_CARE and WARN in
cpuid_entry2_find() if index is significant and index == DONT_CARE.
I'll fiddle with this, unless you want the honors?
> Also, the kvm_cpuid() reference needs to be changed, which I did upon
> commit.
Doh, thanks!
Powered by blists - more mailing lists