public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@intel.com>
To: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xin@zytor.com" <xin@zytor.com>
Cc: "Yang, Weijiang" <weijiang.yang@intel.com>, "Christopherson,,
	Sean" <seanjc@google.com>, "x86@kernel.org" <x86@kernel.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"bp@alien8.de" <bp@alien8.de>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [PATCH v3 1/2] KVM: VMX: Cleanup VMX basic information defines and usages
Date: Tue, 31 Oct 2023 09:03:22 +0000	[thread overview]
Message-ID: <2158ef3c5ce2de96c970b49802b7e1dba8b704d6.camel@intel.com> (raw)
In-Reply-To: <20231030233940.438233-1-xin@zytor.com>

On Mon, 2023-10-30 at 16:39 -0700, Xin Li (Intel) wrote:
> From: Xin Li <xin3.li@intel.com>
> 
> Define VMX basic information fields with BIT_ULL()/GENMASK_ULL(), and
> replace hardcoded VMX basic numbers with these field macros.
> 
> Per Sean's ask, save the full/raw value of MSR_IA32_VMX_BASIC in the
> global vmcs_config as type u64 to get rid of the hi/lo crud, and then
> use VMX_BASIC helpers to extract info as needed.
> 

[...]

Btw, it's better to have a cover letter even for this small series and give a
lore link for old versions so that people can easily find old discussions.

>  
> +/* x86 memory types, explicitly used in VMX only */
> +#define MEM_TYPE_WB				0x6ULL
> +#define MEM_TYPE_UC				0x0ULL

The renaming of memory type macros deserves some justification in the changelog
IMHO, because it doesn't belong to what the patch title claims to do.

You can even split this part out, but will leave to Sean/Paolo.

> +
> +/* VMX_BASIC bits and bitmasks */
> +#define VMX_BASIC_32BIT_PHYS_ADDR_ONLY		BIT_ULL(48)
> +#define VMX_BASIC_INOUT				BIT_ULL(54)
> +
>  #define VMX_MISC_PREEMPTION_TIMER_RATE_MASK	0x0000001f
>  #define VMX_MISC_SAVE_EFER_LMA			0x00000020
>  #define VMX_MISC_ACTIVITY_HLT			0x00000040
> @@ -143,6 +151,16 @@ static inline u32 vmx_basic_vmcs_size(u64 vmx_basic)
>  	return (vmx_basic & GENMASK_ULL(44, 32)) >> 32;
>  }
>  
> +static inline u32 vmx_basic_vmcs_basic_cap(u64 vmx_basic)
> +{
> +	return (vmx_basic & GENMASK_ULL(63, 45)) >> 32;
> +}

Is this still needed?

> +
> +static inline u32 vmx_basic_vmcs_mem_type(u64 vmx_basic)
> +{
> +	return (vmx_basic & GENMASK_ULL(53, 50)) >> 50;
> +}

You already have VMX_BASIC_MEM_TYPE_SHIFT defined below, so it looks a little
bit odd to still use hard-coded values here.

But per Sean I agree it's quite noisy to have all these _SHIFT defined just in
order to get rid of these hard-coded values.

How about, ...

> +#define VMX_BASIC_VMCS_SIZE_SHIFT		32
> +#define VMX_BASIC_DUAL_MONITOR_TREATMENT	BIT_ULL(49)
> +#define VMX_BASIC_MEM_TYPE_SHIFT		50
> +#define VMX_BASIC_TRUE_CTLS			BIT_ULL(55)
> +
> 

... since, if I am reading correctly, the two _SHIFT above are only used ...

[...]

> @@ -6964,7 +6975,7 @@ static void nested_vmx_setup_basic(struct nested_vmx_msrs *msrs)
>  		VMCS12_REVISION |
>  		VMX_BASIC_TRUE_CTLS |
>  		((u64)VMCS12_SIZE << VMX_BASIC_VMCS_SIZE_SHIFT) |
> -		(VMX_BASIC_MEM_TYPE_WB << VMX_BASIC_MEM_TYPE_SHIFT);
> +		(MEM_TYPE_WB << VMX_BASIC_MEM_TYPE_SHIFT);
>  

... here, we can remove the two _SHIFT but define below instead:

  #define VMX_BASIC_VMCS12_SIZE	((u64)VMCS12_SIZE << 32)
  #define VMX_BASIC_MEM_TYPE_WB	(MEM_TYPE_WB << 50)

And use above two macros in nested_vmx_setup_basic()?

  parent reply	other threads:[~2023-10-31  9:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-30 23:39 [PATCH v3 1/2] KVM: VMX: Cleanup VMX basic information defines and usages Xin Li (Intel)
2023-10-30 23:39 ` [PATCH v3 2/2] KVM: VMX: Cleanup VMX misc " Xin Li (Intel)
2023-10-31  9:03 ` Huang, Kai [this message]
2023-10-31 17:28   ` [PATCH v3 1/2] KVM: VMX: Cleanup VMX basic " Xin Li
2024-01-12  9:51     ` Li, Xin3

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=2158ef3c5ce2de96c970b49802b7e1dba8b704d6.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=weijiang.yang@intel.com \
    --cc=x86@kernel.org \
    --cc=xin@zytor.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