xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Keir Fraser <keir@xen.org>,
	Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
	suravee.suthikulpanit@amd.com
Subject: Re: [PATCH v2 2/3] x86/AMD: support further feature masking MSRs
Date: Mon, 7 Apr 2014 11:23:21 +0100	[thread overview]
Message-ID: <53427C99.8010905@citrix.com> (raw)
In-Reply-To: <53428F4402000078000060BB@nat28.tlf.novell.com>


[-- Attachment #1.1: Type: text/plain, Size: 7874 bytes --]

On 07/04/14 10:43, Jan Beulich wrote:
> Newer AMD CPUs also allow masking CPUID leaf 6 ECX and CPUID leaf 7
> sub-leaf 0 EAX and EBX.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Aravind Gopalakrishnan<aravind.gopalakrishnan@amd.com>
> ---
> v2: Adjust for new prior patch. Apply leaf 6 mask only on Fam15.
>
> --- 2014-03-17.orig/docs/misc/xen-command-line.markdown	2014-04-04 11:27:32.000000000 +0200
> +++ 2014-03-17/docs/misc/xen-command-line.markdown	2014-03-18 14:37:31.000000000 +0100
> @@ -331,24 +331,42 @@ Indicate where the responsibility for dr
>  ### cpuid\_mask\_cpu (AMD only)
>  > `= fam_0f_rev_c | fam_0f_rev_d | fam_0f_rev_e | fam_0f_rev_f | fam_0f_rev_g | fam_10_rev_b | fam_10_rev_c | fam_11_rev_b`
>  
> -If the other **cpuid\_mask\_{,ext\_}e{c,d}x** options are fully set
> -(unspecified on the command line), specify a pre-canned cpuid mask to
> -mask the current processor down to appear as the specified processor.
> -It is important to ensure that all hosts in a pool appear the same to
> -guests to allow successful live migration.
> +If the other **cpuid\_mask\_{,ext\_,thermal\_,l7s0\_}e{a,b,c,d}x**
> +options are fully set (unspecified on the command line), specify a
> +pre-canned cpuid mask to mask the current processor down to appear as
> +the specified processor. It is important to ensure that all hosts in a
> +pool appear the same to guests to allow successful live migration.
>  
> -### cpuid\_mask\_ ecx,edx,ext\_ecx,ext\_edx,xsave_eax
> +### cpuid\_mask\_{{,ext\_}ecx,edx}
>  > `= <integer>`
>  
>  > Default: `~0` (all bits set)
>  
> -These five command line parameters are used to specify cpuid masks to
> +These four command line parameters are used to specify cpuid masks to
>  help with cpuid levelling across a pool of hosts.  Setting a bit in
>  the mask indicates that the feature should be enabled, while clearing
>  a bit in the mask indicates that the feature should be disabled.  It
>  is important to ensure that all hosts in a pool appear the same to
>  guests to allow successful live migration.
>  
> +### cpuid\_mask\_xsave\_eax (Intel only)
> +> `= <integer>`
> +
> +> Default: `~0` (all bits set)
> +
> +This command line parameter is also used to specify a cpuid mask to
> +help with cpuid levelling across a pool of hosts.  See the description
> +of the other respective options above.
> +
> +### cpuid\_mask\_{l7s0\_{eax,ebx},thermal\_ecx} (AMD only)
> +> `= <integer>`
> +
> +> Default: `~0` (all bits set)
> +
> +These three command line parameters are also used to specify cpuid
> +masks to help with cpuid levelling across a pool of hosts.  See the
> +description of the other respective options above.
> +
>  ### cpuidle
>  > `= <boolean>`
>  
> --- 2014-03-17.orig/xen/arch/x86/cpu/amd.c	2014-04-04 11:31:51.000000000 +0200
> +++ 2014-03-17/xen/arch/x86/cpu/amd.c	2014-04-04 11:35:31.000000000 +0200
> @@ -30,9 +30,17 @@
>   * "fam_10_rev_c"
>   * "fam_11_rev_b"
>   */
> -static char opt_famrev[14];
> +static char __initdata opt_famrev[14];
>  string_param("cpuid_mask_cpu", opt_famrev);
>  
> +static unsigned int __initdata opt_cpuid_mask_l7s0_eax = ~0u;
> +integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
> +static unsigned int __initdata opt_cpuid_mask_l7s0_ebx = ~0u;
> +integer_param("cpuid_mask_l7s0_ebx", opt_cpuid_mask_l7s0_ebx);
> +
> +static unsigned int __initdata opt_cpuid_mask_thermal_ecx = ~0u;
> +integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_thermal_ecx);
> +
>  /* 1 = allow, 0 = don't allow guest creation, -1 = don't allow boot */
>  s8 __read_mostly opt_allow_unsafe;
>  boolean_param("allow_unsafe", opt_allow_unsafe);
> @@ -96,7 +104,11 @@ static void __devinit set_cpuidmask(cons
>  {
>  	static unsigned int feat_ecx, feat_edx;
>  	static unsigned int extfeat_ecx, extfeat_edx;
> +	static unsigned int l7s0_eax, l7s0_ebx;
> +	static unsigned int thermal_ecx;
> +	static bool_t skip_l7s0_eax_ebx, skip_thermal_ecx;
>  	static enum { not_parsed, no_mask, set_mask } status;
> +	unsigned int eax, ebx, ecx, edx;
>  
>  	if (status == no_mask)
>  		return;
> @@ -104,7 +116,7 @@ static void __devinit set_cpuidmask(cons
>  	if (status == set_mask)
>  		goto setmask;
>  
> -	ASSERT((status == not_parsed) && (smp_processor_id() == 0));
> +	ASSERT((status == not_parsed) && (c == &boot_cpu_data));
>  	status = no_mask;
>  
>  	/* Fam11 doesn't support masking at all. */
> @@ -112,11 +124,16 @@ static void __devinit set_cpuidmask(cons
>  		return;
>  
>  	if (~(opt_cpuid_mask_ecx & opt_cpuid_mask_edx &
> -	      opt_cpuid_mask_ext_ecx & opt_cpuid_mask_ext_edx)) {
> +	      opt_cpuid_mask_ext_ecx & opt_cpuid_mask_ext_edx &
> +	      opt_cpuid_mask_l7s0_eax & opt_cpuid_mask_l7s0_ebx &
> +	      opt_cpuid_mask_thermal_ecx)) {
>  		feat_ecx = opt_cpuid_mask_ecx;
>  		feat_edx = opt_cpuid_mask_edx;
>  		extfeat_ecx = opt_cpuid_mask_ext_ecx;
>  		extfeat_edx = opt_cpuid_mask_ext_edx;
> +		l7s0_eax = opt_cpuid_mask_l7s0_eax;
> +		l7s0_ebx = opt_cpuid_mask_l7s0_ebx;
> +		thermal_ecx = opt_cpuid_mask_thermal_ecx;
>  	} else if (*opt_famrev == '\0') {
>  		return;
>  	} else if (!strcmp(opt_famrev, "fam_0f_rev_c")) {
> @@ -179,11 +196,39 @@ static void __devinit set_cpuidmask(cons
>  	printk("Writing CPUID extended feature mask ECX:EDX -> %08Xh:%08Xh\n", 
>  	       extfeat_ecx, extfeat_edx);
>  
> +	if (c->cpuid_level >= 7)
> +		cpuid_count(7, 0, &eax, &ebx, &ecx, &edx);
> +	else
> +		ebx = eax = 0;
> +	if ((eax | ebx) && ~(l7s0_eax & l7s0_ebx)) {
> +		if (l7s0_eax > eax)
> +			l7s0_eax = eax;
> +		l7s0_ebx &= ebx;
> +		printk("Writing CPUID leaf 7 subleaf 0 feature mask EAX:EBX -> %08Xh:%08Xh\n",
> +		       l7s0_eax, l7s0_ebx);
> +	} else
> +		skip_l7s0_eax_ebx = 1;
> +
> +	/* Only Fam15 has the respective MSR. */
> +	ecx = c->x86 == 0x15 && c->cpuid_level >= 6 ? cpuid_ecx(6) : 0;
> +	if (ecx && ~thermal_ecx) {
> +		thermal_ecx &= ecx;
> +		printk("Writing CPUID thermal/power feature mask ECX -> %08Xh\n",
> +		       thermal_ecx);
> +	} else
> +		skip_thermal_ecx = 1;
> +
>   setmask:
>  	/* AMD processors prior to family 10h required a 32-bit password */
>  	if (c->x86 >= 0x10) {
>  		wrmsr(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
>  		wrmsr(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);
> +		if (!skip_l7s0_eax_ebx)
> +			wrmsr(MSR_AMD_L7S0_FEATURE_MASK, l7s0_ebx, l7s0_eax);
> +		if (!skip_thermal_ecx) {
> +			rdmsr(MSR_AMD_THRM_FEATURE_MASK, eax, edx);
> +			wrmsr(MSR_AMD_THRM_FEATURE_MASK, thermal_ecx, edx);
> +		}
>  	} else {
>  		wrmsr_amd(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
>  		wrmsr_amd(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);

While editing this, can we remove this crazy split between wrmsr and
wrmsr_amd ?  It is safe to use wrmsr_amd in all cases where wrmsr is needed.

I already did this as part of the prep work for per-VM masking, but in
combination with above, the following should be fine:

wrmsr_amd(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
wrmsr_amd(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);
if (!skip_l7s0_eax_ebx)
    wrmsr(MSR_AMD_L7S0_FEATURE_MASK, l7s0_ebx, l7s0_eax);
if (!skip_thermal_ecx) {
    rdmsr(MSR_AMD_THRM_FEATURE_MASK, eax, edx);
    wrmsr(MSR_AMD_THRM_FEATURE_MASK, thermal_ecx, edx);
}

~Andrew

> --- 2014-03-17.orig/xen/include/asm-x86/msr-index.h	2014-03-10 11:36:00.000000000 +0100
> +++ 2014-03-17/xen/include/asm-x86/msr-index.h	2014-03-18 12:19:10.000000000 +0100
> @@ -192,6 +192,8 @@
>  #define MSR_AMD_FAM15H_EVNTSEL5		0xc001020a
>  #define MSR_AMD_FAM15H_PERFCTR5		0xc001020b
>  
> +#define MSR_AMD_L7S0_FEATURE_MASK	0xc0011002
> +#define MSR_AMD_THRM_FEATURE_MASK	0xc0011003
>  #define MSR_K8_FEATURE_MASK		0xc0011004
>  #define MSR_K8_EXT_FEATURE_MASK		0xc0011005
>  
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 8809 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2014-04-07 10:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07  9:36 [PATCH v2 0/3] x86/AMD: feature masking adjustments Jan Beulich
2014-04-07  9:41 ` [PATCH v2 1/3] x86/AMD: feature masking is unavailable on Fam11 Jan Beulich
2014-04-07 10:14   ` Andrew Cooper
2014-04-07  9:43 ` [PATCH v2 2/3] x86/AMD: support further feature masking MSRs Jan Beulich
2014-04-07 10:23   ` Andrew Cooper [this message]
2014-04-07 11:53     ` Jan Beulich
2014-04-07 12:09       ` Andrew Cooper
2014-04-07 15:21   ` Boris Ostrovsky
2014-04-08  7:15     ` Jan Beulich
2014-04-08 13:50       ` Boris Ostrovsky
2014-04-08 14:02         ` Jan Beulich
2014-04-08 14:14           ` Boris Ostrovsky
2014-04-08 14:33             ` Jan Beulich
2014-04-08 15:14               ` Boris Ostrovsky
2014-04-09 15:39                 ` Aravind Gopalakrishnan
2014-04-09 15:50                   ` Jan Beulich
2014-04-07  9:43 ` [PATCH v2 3/3] x86/AMD: clean up pre-canned family/revision handling for CPUID masking Jan Beulich
2014-04-07 10:48   ` Andrew Cooper
2014-04-07 11:55     ` Jan Beulich

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=53427C99.8010905@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=aravind.gopalakrishnan@amd.com \
    --cc=keir@xen.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=xen-devel@lists.xenproject.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 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).