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: Wed, 15 Jan 2014 15:07:36 -0500 Message-ID: <20140115200736.GB5201@phenom.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1W3Wlb-0003pn-L5 for xen-devel@lists.xenproject.org; Wed, 15 Jan 2014 20:08:47 +0000 Content-Disposition: inline In-Reply-To: <52D3E1500200007800113058@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, Ian Campbell , jun.nakajima@intel.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org 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? > > Jan >