From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. Date: Tue, 11 Nov 2014 10:45:56 -0500 Message-ID: <20141111154556.GD6597@laptop.dumpdata.com> References: <20140110184151.GA20232@pegasus.dumpdata.com> <1389607803.8187.22.camel@kazak.uk.xensource.com> <52D3DC730200007800112FF6@nat28.tlf.novell.com> <1389613109.13654.43.camel@kazak.uk.xensource.com> <52D3E1500200007800113058@nat28.tlf.novell.com> <20140115200736.GB5201@phenom.dumpdata.com> <20141110145720.GH3783@laptop.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XoDe1-0005cT-Lu for xen-devel@lists.xenproject.org; Tue, 11 Nov 2014 15:46:13 +0000 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Zhang, Yang Z" Cc: Ian Campbell , "stefano.stabellini@eu.citrix.com" , "Li, Liang Z" , "ian.jackson@eu.citrix.com" , Jan Beulich , "Nakajima, Jun" , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org On Tue, Nov 11, 2014 at 03:30:54AM +0000, Zhang, Yang Z wrote: > Konrad Rzeszutek Wilk wrote on 2014-11-10: > > 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 > > 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! > > OK. We will provide a patch ASAP. Excellent. Looking forward to it! > > Best regards, > Yang > >