All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zeng Guang <guang.zeng@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.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" <kvm@vger.kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Kim Phillips <kim.phillips@amd.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Jethro Beekman <jethro@fortanix.com>,
	"Huang, Kai" <kai.huang@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Hu, Robert" <robert.hu@intel.com>,
	"Gao, Chao" <chao.gao@intel.com>,
	Robert Hoo <robert.hu@linux.intel.com>
Subject: Re: [PATCH 1/6] x86/feat_ctl: Add new VMX feature, Tertiary VM-Execution control
Date: Mon, 2 Aug 2021 16:22:32 +0800	[thread overview]
Message-ID: <ad88a2ed-536e-deae-2428-278346a43d30@intel.com> (raw)
In-Reply-To: <YQHr6VvNOQclolfc@google.com>

On 7/29/2021 7:44 AM, Sean Christopherson wrote:
> On Fri, Jul 16, 2021, Zeng Guang wrote:
>> From: Robert Hoo <robert.hu@linux.intel.com>
>>
>> New VMX capability MSR IA32_VMX_PROCBASED_CTLS3 conresponse to this new
>> VM-Execution control field. And it is 64bit allow-1 semantics, not like
>> previous capability MSRs 32bit allow-0 and 32bit allow-1. So with Tertiary
>> VM-Execution control field introduced, 2 vmx_feature leaves are introduced,
>> TERTIARY_CTLS_LOW and TERTIARY_CTLS_HIGH.
> ...
>
>>   /*
>>    * Note: If the comment begins with a quoted string, that string is used
>> @@ -43,6 +43,7 @@
>>   #define VMX_FEATURE_RDTSC_EXITING	( 1*32+ 12) /* "" VM-Exit on RDTSC */
>>   #define VMX_FEATURE_CR3_LOAD_EXITING	( 1*32+ 15) /* "" VM-Exit on writes to CR3 */
>>   #define VMX_FEATURE_CR3_STORE_EXITING	( 1*32+ 16) /* "" VM-Exit on reads from CR3 */
>> +#define VMX_FEATURE_TER_CONTROLS	(1*32 + 17) /* "" Enable Tertiary VM-Execution Controls */
> Maybe spell out TERTIARY?   SEC_CONTROLS is at least somewhat guessable, I doubt
> TERTIARY is the first thing that comes to mind for most people when seeing "TER" :-)
Agree. TERTIARY could be readable without any confusion.
>>   #define VMX_FEATURE_CR8_LOAD_EXITING	( 1*32+ 19) /* "" VM-Exit on writes to CR8 */
>>   #define VMX_FEATURE_CR8_STORE_EXITING	( 1*32+ 20) /* "" VM-Exit on reads from CR8 */
>>   #define VMX_FEATURE_VIRTUAL_TPR		( 1*32+ 21) /* "vtpr" TPR virtualization, a.k.a. TPR shadow */
>> diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c
>> index da696eb4821a..2e0272d127e4 100644
>> --- a/arch/x86/kernel/cpu/feat_ctl.c
>> +++ b/arch/x86/kernel/cpu/feat_ctl.c
>> @@ -15,6 +15,8 @@ enum vmx_feature_leafs {
>>   	MISC_FEATURES = 0,
>>   	PRIMARY_CTLS,
>>   	SECONDARY_CTLS,
>> +	TERTIARY_CTLS_LOW,
>> +	TERTIARY_CTLS_HIGH,
>>   	NR_VMX_FEATURE_WORDS,
>>   };
>>   
>> @@ -42,6 +44,13 @@ static void init_vmx_capabilities(struct cpuinfo_x86 *c)
>>   	rdmsr_safe(MSR_IA32_VMX_PROCBASED_CTLS2, &ign, &supported);
>>   	c->vmx_capability[SECONDARY_CTLS] = supported;
>>   
>> +	/*
>> +	 * For tertiary execution controls MSR, it's actually a 64bit allowed-1.
>> +	 */
>> +	rdmsr_safe(MSR_IA32_VMX_PROCBASED_CTLS3, &ign, &supported);
>> +	c->vmx_capability[TERTIARY_CTLS_LOW] = ign;
>> +	c->vmx_capability[TERTIARY_CTLS_HIGH] = supported;
> Assuming only the lower 32 bits are going to be used for the near future (next
> few years), what about defining just TERTIARY_CTLS_LOW and then doing:
>
> 	/*
> 	 * Tertiary controls are 64-bit allowed-1, so unlikely other MSRs, the
> 	 * upper bits are ignored (because they're not used, yet...).
> 	 */
> 	rdmsr_safe(MSR_IA32_VMX_PROCBASED_CTLS3, &supported, &ign);
> 	c->vmx_capability[TERTIARY_CTLS_LOW] = supported;
>
> I.e. punt the ugliness issue down the road a few years.
Prefer to keep it complete, and use new variables like low/high 
consistent with its function meaning. Ok for that ?
>> +
>>   	rdmsr(MSR_IA32_VMX_PINBASED_CTLS, ign, supported);
>>   	rdmsr_safe(MSR_IA32_VMX_VMFUNC, &ign, &funcs);
>>   
>> -- 
>> 2.25.1
>>

  parent reply	other threads:[~2021-08-02  8:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16  6:48 [PATCH 0/5] IPI virtualization support for VM Zeng Guang
2021-07-16  6:48 ` [PATCH 1/6] x86/feat_ctl: Add new VMX feature, Tertiary VM-Execution control Zeng Guang
2021-07-28 23:44   ` Sean Christopherson
2021-07-29 15:56     ` Paolo Bonzini
2021-08-02  8:22     ` Zeng Guang [this message]
2021-08-02 16:20       ` Sean Christopherson
2021-07-16  6:48 ` [PATCH 2/6] KVM: VMX: Extend BUILD_CONTROLS_SHADOW macro to support 64-bit variation Zeng Guang
2021-07-16  6:48 ` [PATCH 3/6] KVM: VMX: Detect Tertiary VM-Execution control when setup VMCS config Zeng Guang
2021-07-29  0:03   ` Sean Christopherson
2021-08-02  6:59     ` Zeng Guang
2021-07-16  6:48 ` [PATCH 4/6] KVM: VMX: dump_vmcs() reports tertiary_exec_control field as well Zeng Guang
2021-07-16  6:48 ` [PATCH 5/6] KVM: x86: Support interrupt dispatch in x2APIC mode with APIC-write VM exit Zeng Guang
2021-07-16  6:48 ` [PATCH 6/6] KVM: VMX: enable IPI virtualization Zeng Guang
2021-07-16  9:52   ` Paolo Bonzini
2021-07-17  3:55     ` Zeng Guang
2021-07-18 20:32       ` Paolo Bonzini
2021-07-19 12:38         ` Zeng Guang
2021-07-19 13:58           ` Paolo Bonzini
2021-07-20  1:07             ` Zeng Guang
2021-07-19 13:16         ` Zeng Guang
2021-07-16  9:25 ` [PATCH 0/5] IPI virtualization support for VM Wanpeng Li
2021-07-17  1:46   ` Zeng Guang
2021-07-19  7:26   ` Zeng Guang
2021-07-19  7:37     ` Wanpeng Li
2021-07-23  6:15       ` Zeng Guang

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=ad88a2ed-536e-deae-2428-278346a43d30@intel.com \
    --to=guang.zeng@intel.com \
    --cc=bp@alien8.de \
    --cc=chao.gao@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=jethro@fortanix.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kai.huang@intel.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kim.phillips@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=robert.hu@intel.com \
    --cc=robert.hu@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /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.