Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 9 Jan 2023 18:13:00 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Vishal Annapurve <vannapurve@google.com>
Cc:     x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org, pbonzini@redhat.com,
        shuah@kernel.org, bgardon@google.com, oupton@google.com,
        peterx@redhat.com, vkuznets@redhat.com, dmatlack@google.com
Subject: Re: [V4 PATCH 2/4] KVM: selftests: x86: Add variables to store cpu
 type
Message-ID: <Y7xZLB+1isqZTJCj@google.com>
References: <20221228192438.2835203-1-vannapurve@google.com>
 <20221228192438.2835203-3-vannapurve@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221228192438.2835203-3-vannapurve@google.com>
Precedence: bulk

In shortlogs and changelogs, try to provide a synopsis of the change, not a
literal description of the change.  As suggested in the previous patch, this:

  KVM: selftests: Cache host CPU vendor (AMD vs. Intel)

is more precise (vendor instead of "cpu type") and hints at the intent (caching
the information), whereas this doesn't capture the vendor part, nor does it provide
any hint whatsoever as to (a) how the variables will be used or (b) why we want to
add variables to store

  KVM: selftests: x86: Add variables to store cpu type

On Wed, Dec 28, 2022, Vishal Annapurve wrote:
> Add variables to hold the cpu vendor type that are initialized early
> during the selftest setup and later synced to guest vm post VM creation.
> 
> These variables will be used in later patches to avoid querying CPU
> type multiple times.

Performance is a happy bonus, it is not the main reason for caching.  The main
reason for caching is so that the guest can select the native hypercall instruction
without having to make assumptions about guest vs. host CPUID information.