All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>,
	"Li, Liang Z" <liang.z.li@intel.com>,
	"ian.jackson@eu.citrix.com" <ian.jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.
Date: Mon, 10 Nov 2014 09:57:20 -0500	[thread overview]
Message-ID: <20141110145720.GH3783@laptop.dumpdata.com> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0ABD8C46@SHSMSX104.ccr.corp.intel.com>

On Mon, Nov 10, 2014 at 05:08:09AM +0000, Zhang, Yang Z wrote:
> Konrad Rzeszutek Wilk wrote on 2014-01-16:
> > On Mon, Jan 13, 2014 at 11:51:28AM +0000, Jan Beulich wrote:
> >>>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>> On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote:
> >>>> In fact I can't see where this would be forced off:
> >>>> xc_cpuid_x86.c only does so in the PV case, and all
> >>>> hvm_pse1gb_supported() is that the CPU supports it and the domain uses HAP.
> >>> 
> >>> Took me a while to spot it too:
> >>> static void intel_xc_cpuid_policy( [...]
> >>>             case 0x80000001: {
> >>>                 int is_64bit = hypervisor_is_64bit(xch) && is_pae;
> >>>                 
> >>>                 /* Only a few features are advertised in Intel's
> >>>                 0x80000001. */ regs[2] &= (is_64bit ?
> > bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
> >>> 
> > bitmaskof(X86_FEATURE_ABM);
> >>>                 regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) :
> >>> 0)
> > |
> >>>                             (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0)
> >>>                             | (is_64bit ?
> >>>                             bitmaskof(X86_FEATURE_SYSCALL) : 0) |
> >>>                             (is_64bit ?
> > bitmaskof(X86_FEATURE_RDTSCP) : 0));
> >>>                 break;
> >>>             }
> >>> 
> >>> Which masks anything which is not explicitly mentioned. (PAGE1GB
> >>> is in regs[3], I think).
> >> 
> >> Ah, okay. The funs of white listing on HVM vs black listing on PV
> >> again.
> >> 
> >>> The AMD version is more permissive:
> >>> 
> >>>         regs[3] &= (0x0183f3ff | /* features shared with
> > 0x00000001:EDX */
> >>>                     (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
> >>>                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
> >>>                     bitmaskof(X86_FEATURE_SYSCALL) |
> >>>                     bitmaskof(X86_FEATURE_MP) |
> >>>                     bitmaskof(X86_FEATURE_MMXEXT) |
> >>>                     bitmaskof(X86_FEATURE_FFXSR) |
> >>>                     bitmaskof(X86_FEATURE_3DNOW) |
> >>>                     bitmaskof(X86_FEATURE_3DNOWEXT));
> >>> (but I didn't check if PAGE1GB is in that magic number...)
> >> 
> >> It's not - it's bit 26.
> > 
> > So.. it sounds to me like everybody is in the agreement that this is
> > the right thing to do (enable it if the hypervisor has it enabled)?
> > 
> > And the next thing is actually come up with a patch to do some of this
> > plumbing - naturally for Xen 4.5?
> 
> Hi, Konrad,
> 
> Is there any patch to turn on the 1GB hugepages? If no, we are happy to give a patch to do it.

I have not see a patch for this, and I would be quite happy to see patch
developed for this!

  reply	other threads:[~2014-11-10 14:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-10 18:41 1GB hugepages and intel_xc_cpuid_policy by default disables it Konrad Rzeszutek Wilk
2014-01-13 10:10 ` Ian Campbell
2014-01-13 11:30   ` Jan Beulich
2014-01-13 11:38     ` Ian Campbell
2014-01-13 11:51       ` Jan Beulich
2014-01-15 20:07         ` Konrad Rzeszutek Wilk
2014-01-16  7:49           ` Jan Beulich
2014-11-10  5:08           ` Zhang, Yang Z
2014-11-10 14:57             ` Konrad Rzeszutek Wilk [this message]
2014-11-11  3:30               ` Zhang, Yang Z
2014-11-11 15:45                 ` Konrad Rzeszutek Wilk

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=20141110145720.GH3783@laptop.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=liang.z.li@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yang.z.zhang@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 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.