All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: David Hildenbrand <david@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: nVMX: INVPCID support
Date: Tue, 1 Aug 2017 19:37:39 +0200	[thread overview]
Message-ID: <20170801173739.GA316@flask> (raw)
In-Reply-To: <ae1bebea-43d1-6c69-ff0d-c1168450a202@redhat.com>

2017-08-01 13:35+0200, Paolo Bonzini:
> On 01/08/2017 13:18, David Hildenbrand wrote:
> > 
> >>> Can't we rewrite that a little bit, avoiding that "best" handling
> >>> (introducing guest_cpuid_disable_invpcid() and guest_cpuid_has_invpcid())
> >>>
> >>> bool invpcid_enabled = guest_cpuid_has_pcid(vcpu) &&
> >>> 		       guest_cpuid_has_invpcid();
> >>>
> >>> if (!invpcid_enabled) {
> >>> 	secondary_exec_ctl &= ~SECONDARY_EXEC_ENABLE_INVPCID;
> >>> 	/* make sure there is no no INVPCID without PCID */
> >>> 	guest_cpuid_disable_invpcid(vcpu);
> >>> }
> >>
> >> I don't know... if you need a comment, it means the different structure
> >> of the code doesn't spare many doubts from the reader.  And the code
> >> doesn't become much simpler since you have to handle "nested" anyway.
> >> What I tried to do was to mimic as much as possible the rdtscp case, but
> >> it cannot be exactly the same due to the interaction between PCID and
> >> INVPCID.
> > 
> > It's more about the handling of best here, which can be avoided quite
> > easily as I showed (by encapsulating how cpuids are looked up/modified).
> 
> Yeah, I don't like either option. :)  Luckily there is a second maintainer!

With three people, we'll just have three options! :)
I'd go with Paolo's version, because it is efficient and also follows
patterns the bit clearing in kvm_update_cpuid().

---
I would like the wrappers if they were more generic, e.g.:

   guest_cpuid_has(vcpu, X86_FEATURE_INVPCID);
   guest_cpuid_clear(vcpu, X86_FEATURE_INVPCID);

To do that, we need a mapping from X86_FEATURE to (leaf, subleaf,
register) triple, which can be done with cpuid_leafs.

I haven't tried to compile the idea below, but if the optimizer is good,
then we should have only slightly worse byte code as we do now thanks to
x86_feature being a compile-time constant.

Do you it's less ugly than the other two options?


static inline bool x86_feature_cpuid(int x86_feature, int *id, int *count, int *register)
{
	static struct {int x86_leaf; int id; int count; int register;} cpuid[] = {
		{CPUID_1_EDX, 1, 0, 3},
		{CPUID_8000_0001_EDX, 0x80000001, 0, 3},
		{CPUID_8086_0001_EDX, 0x80860001, 0, 3},
		{CPUID_1_ECX, 1, 0, 2},
		... // you get the idea, it's tedious :)
		};
	
	for (size_t i = 0; i < ARRAY_SIZE(cpuid); i++)
		if (cpuid[i].x86_leaf == x86_feature / 32) {
			*id = cpuid[i].id;
			*count = cpuid[i].count;
			*register = cpuid[i].register;
			return true;
		}
	
	return false;
}

static inline bool guest_cpuid_has(struct kvm_vcpu *vcpu, int x86_feature)
{
	int id, count, register;
	u32 *reg;
	struct kvm_cpuid_entry2 *best;

	if (!x86_feature_cpuid(x86_feature, &id, &count, &register))
		return false;

	if (!(best = kvm_find_cpuid_entry(id, count)))
		return false;

	reg = &best->eax + register; // rewrite to be safer
	return *reg & bit(x86_feature);
}

Similar for guest_cpuid_clear and we can also factor out the common part
for getting the register (all up to the last line, with NULL as failure)

  reply	other threads:[~2017-08-01 17:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-27 13:20 [PATCH] KVM: nVMX: INVPCID support Paolo Bonzini
2017-07-27 18:29 ` David Hildenbrand
2017-07-27 19:04   ` Paolo Bonzini
2017-08-01 10:48   ` Paolo Bonzini
2017-08-01 11:18     ` David Hildenbrand
2017-08-01 11:35       ` Paolo Bonzini
2017-08-01 17:37         ` Radim Krčmář [this message]
2017-08-02  7:38           ` Paolo Bonzini
2017-08-02  8:50             ` David Hildenbrand
  -- strict thread matches above, loose matches on Subject: below --
2017-07-27 12:42 Paolo Bonzini

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=20170801173739.GA316@flask \
    --to=rkrcmar@redhat.com \
    --cc=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.