kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Xiaoyao Li <xiaoyao.li@intel.com>
Subject: Re: [PATCH 3/6] KVM: x86: Add dedicated emulator helper for grabbing CPUID.maxphyaddr
Date: Wed, 4 Mar 2020 12:47:40 -0800	[thread overview]
Message-ID: <20200304204740.GG21662@linux.intel.com> (raw)
In-Reply-To: <4ddde497-9c71-d64c-df20-3b4439664336@redhat.com>

On Tue, Mar 03, 2020 at 11:14:22AM +0100, Paolo Bonzini wrote:
> On 03/03/20 10:48, Jan Kiszka wrote:
> >>
> >> I don't think this is a particularly useful change.  Yes, it's not
> >> intuitive but is it more than a matter of documentation (and possibly
> >> moving the check_cr_write snippet into a separate function)?
> > 
> > Besides the non obvious return value of the current function, this
> > approach also avoids leaving cpuid traces for querying maxphyaddr, which
> > is also not very intuitive IMHO.
> 
> There are already other cases where we leave CPUID traces.  We can just
> stop tracing if check_limit (which should be renamed to from_guest) is
> true; there are other internal cases which call ctxt->ops->get_cpuid,
> such as vendor_intel, and those should also use check_limit==true and
> check the return value of ctxt->ops->get_cpuid.

No, the vendor checks that use get_cpuid() shouldn't do check_limit=true,
they're looking for an exact match on the vendor.

Not that it matters.  @check_limit only comes into play on a vendor check
if CPUID.0 doesn't exist, and @check_limit only effects the output if
CPUID.0 _does_ exist.  I.e. the output for CPUID.0 is unaffected by
@check_limit.

  reply	other threads:[~2020-03-04 20:47 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02 19:57 [PATCH 0/6] KVM: x86: CPUID emulation and tracing fixes Sean Christopherson
2020-03-02 19:57 ` [PATCH 1/6] KVM: x86: Fix tracing of CPUID.function when function is out-of-range Sean Christopherson
2020-03-02 20:26   ` Jan Kiszka
2020-03-02 20:49     ` Sean Christopherson
2020-03-02 20:59       ` Jan Kiszka
2020-03-03  2:27       ` Xiaoyao Li
2020-03-03  3:45         ` Sean Christopherson
2020-03-03  4:02           ` Xiaoyao Li
2020-03-03  4:12             ` Sean Christopherson
2020-03-03  4:30               ` Xiaoyao Li
2020-03-03  2:50   ` Xiaoyao Li
2020-03-03  4:08     ` Sean Christopherson
2020-03-03  4:16       ` Xiaoyao Li
2020-03-02 19:57 ` [PATCH 2/6] KVM: x86: Fix CPUID range check for Centaur and Hypervisor ranges Sean Christopherson
2020-03-02 21:59   ` Jim Mattson
2020-03-03  0:57     ` Sean Christopherson
2020-03-03  3:25   ` Jim Mattson
2020-03-03  4:25     ` Jim Mattson
2020-03-03  4:58       ` Sean Christopherson
2020-03-03 17:42         ` Jim Mattson
2020-03-03 18:01           ` Sean Christopherson
2020-03-03 18:08             ` Jim Mattson
2020-03-04 11:18             ` Paolo Bonzini
2020-03-02 19:57 ` [PATCH 3/6] KVM: x86: Add dedicated emulator helper for grabbing CPUID.maxphyaddr Sean Christopherson
2020-03-03  8:48   ` Paolo Bonzini
2020-03-03  9:48     ` Jan Kiszka
2020-03-03 10:14       ` Paolo Bonzini
2020-03-04 20:47         ` Sean Christopherson [this message]
2020-03-03 16:28     ` Sean Christopherson
2020-03-03 17:21       ` Paolo Bonzini
2020-03-02 19:57 ` [PATCH 4/6] KVM: x86: Drop return value from kvm_cpuid() Sean Christopherson
2020-03-02 19:57 ` [PATCH 5/6] KVM: x86: Rename "found" variable in kvm_cpuid() to "exact_entry_exists" Sean Christopherson
2020-03-02 20:20   ` Jan Kiszka
2020-03-02 20:35     ` Sean Christopherson
2020-03-02 20:48       ` Jan Kiszka
2020-03-02 19:57 ` [PATCH 6/6] KVM: x86: Add requested index to the CPUID tracepoint Sean Christopherson
2020-03-07  9:48   ` Jan Kiszka
2020-03-10  4:00     ` Sean Christopherson
2020-03-03  8:48 ` [PATCH 0/6] KVM: x86: CPUID emulation and tracing fixes Paolo Bonzini
2020-03-03 16:38   ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200304204740.GG21662@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=xiaoyao.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).