* 1GB hugepages and intel_xc_cpuid_policy by default disables it. @ 2014-01-10 18:41 Konrad Rzeszutek Wilk 2014-01-13 10:10 ` Ian Campbell 0 siblings, 1 reply; 11+ messages in thread From: Konrad Rzeszutek Wilk @ 2014-01-10 18:41 UTC (permalink / raw) To: xen-devel, ian.jackson, stefano.stabellini, ian.campbell, jun.nakajima Hey, It occured to me that when booting Linux HVM guests, the 1GB hugepage cpuid is not exposed. One needs to manually do: cpuid= ['0x80000001:edx=xxxxx1xxxxxxxxxxxxxxxxxxxxxxxxxx'] or cpuid="host,page1gb=k" (see http://lists.xenproject.org/archives/html/xen-users/2013-09/msg00083.html for some discussion about it). The machine I am using is supporting it: (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB and this is the only way to get hugepages working (for reference here is what I have in the guest command line: "default_hugepagesz=1G hugepagesz=1G hugepages=2 hugepagesz=2M hugepages=100" and without this cpuid I get: hugepagesz: Unsupported page size 1024 M because the 1GB flag is not exposed. I was wondering why we don't check the host cpuid and set the 1GB flag (pdpe1gb) for those cases? It seems that all the pieces are in place for this to work? Thanks! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 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 0 siblings, 1 reply; 11+ messages in thread From: Ian Campbell @ 2014-01-13 10:10 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: xen-devel, ian.jackson, jun.nakajima, stefano.stabellini On Fri, 2014-01-10 at 13:41 -0500, Konrad Rzeszutek Wilk wrote: > Hey, > > It occured to me that when booting Linux HVM guests, the 1GB hugepage > cpuid is not exposed. One needs to manually do: > > cpuid= ['0x80000001:edx=xxxxx1xxxxxxxxxxxxxxxxxxxxxxxxxx'] > or > cpuid="host,page1gb=k" > (see http://lists.xenproject.org/archives/html/xen-users/2013-09/msg00083.html > for some discussion about it). > > The machine I am using is supporting it: > > (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB HAP page sizes is unrelated to the page sizes supported in "first stage" paging, although I suppose it is unlikely for EPT to support it without the primary translation supporting it. > and this is the only way to get hugepages working > (for reference here is what I have in the guest command line: > "default_hugepagesz=1G hugepagesz=1G hugepages=2 hugepagesz=2M > hugepages=100" and without this cpuid I get: > hugepagesz: Unsupported page size 1024 M > > because the 1GB flag is not exposed. > > I was wondering why we don't check the host cpuid and set the 1GB > flag (pdpe1gb) for those cases? It seems that all the pieces are in > place for this to work? The hypervisor currently contains : /* Hide 1GB-superpage feature if we can't emulate it. */ if (!hvm_pse1gb_supported(d)) *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB); So I think it would be safe to enable this by default in userspace and let the hypervisor clear it if unsafe. But TBH the whole cpuid policy is a mystery to me. Can you cc some likely hypervisor side people on your patch for confirmation please. Ian. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 2014-01-13 10:10 ` Ian Campbell @ 2014-01-13 11:30 ` Jan Beulich 2014-01-13 11:38 ` Ian Campbell 0 siblings, 1 reply; 11+ messages in thread From: Jan Beulich @ 2014-01-13 11:30 UTC (permalink / raw) To: Ian Campbell, Konrad Rzeszutek Wilk Cc: xen-devel, ian.jackson, jun.nakajima, stefano.stabellini >>> On 13.01.14 at 11:10, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Fri, 2014-01-10 at 13:41 -0500, Konrad Rzeszutek Wilk wrote: >> and this is the only way to get hugepages working >> (for reference here is what I have in the guest command line: >> "default_hugepagesz=1G hugepagesz=1G hugepages=2 hugepagesz=2M >> hugepages=100" and without this cpuid I get: >> hugepagesz: Unsupported page size 1024 M >> >> because the 1GB flag is not exposed. >> >> I was wondering why we don't check the host cpuid and set the 1GB >> flag (pdpe1gb) for those cases? It seems that all the pieces are in >> place for this to work? > > The hypervisor currently contains : > /* Hide 1GB-superpage feature if we can't emulate it. */ > if (!hvm_pse1gb_supported(d)) > *edx &= ~cpufeat_mask(X86_FEATURE_PAGE1GB); > > So I think it would be safe to enable this by default in userspace and > let the hypervisor clear it if unsafe. But TBH the whole cpuid policy is > a mystery to me. Can you cc some likely hypervisor side people on your > patch for confirmation please. 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. Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 2014-01-13 11:30 ` Jan Beulich @ 2014-01-13 11:38 ` Ian Campbell 2014-01-13 11:51 ` Jan Beulich 0 siblings, 1 reply; 11+ messages in thread From: Ian Campbell @ 2014-01-13 11:38 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel, stefano.stabellini, ian.jackson, jun.nakajima 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). 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...) Ian. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 2014-01-13 11:38 ` Ian Campbell @ 2014-01-13 11:51 ` Jan Beulich 2014-01-15 20:07 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 11+ messages in thread From: Jan Beulich @ 2014-01-13 11:51 UTC (permalink / raw) To: Ian Campbell; +Cc: xen-devel, ian.jackson, jun.nakajima, stefano.stabellini >>> 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. Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 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 0 siblings, 2 replies; 11+ messages in thread From: Konrad Rzeszutek Wilk @ 2014-01-15 20:07 UTC (permalink / raw) To: Jan Beulich Cc: xen-devel, ian.jackson, Ian Campbell, jun.nakajima, stefano.stabellini 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? > > Jan > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 2014-01-15 20:07 ` Konrad Rzeszutek Wilk @ 2014-01-16 7:49 ` Jan Beulich 2014-11-10 5:08 ` Zhang, Yang Z 1 sibling, 0 replies; 11+ messages in thread From: Jan Beulich @ 2014-01-16 7:49 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: xen-devel, ian.jackson, Ian Campbell, jun.nakajima, stefano.stabellini >>> On 15.01.14 at 21:07, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > 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? Yes, so would I think. Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 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 1 sibling, 1 reply; 11+ messages in thread From: Zhang, Yang Z @ 2014-11-10 5:08 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, Jan Beulich Cc: Ian Campbell, stefano.stabellini@eu.citrix.com, Li, Liang Z, ian.jackson@eu.citrix.com, Nakajima, Jun, xen-devel@lists.xenproject.org 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. >> >> Jan >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel Best regards, Yang ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 2014-11-10 5:08 ` Zhang, Yang Z @ 2014-11-10 14:57 ` Konrad Rzeszutek Wilk 2014-11-11 3:30 ` Zhang, Yang Z 0 siblings, 1 reply; 11+ messages in thread From: Konrad Rzeszutek Wilk @ 2014-11-10 14:57 UTC (permalink / raw) 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 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! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 2014-11-10 14:57 ` Konrad Rzeszutek Wilk @ 2014-11-11 3:30 ` Zhang, Yang Z 2014-11-11 15:45 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 11+ messages in thread From: Zhang, Yang Z @ 2014-11-11 3:30 UTC (permalink / raw) To: Konrad Rzeszutek Wilk 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 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 <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! OK. We will provide a patch ASAP. Best regards, Yang ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it. 2014-11-11 3:30 ` Zhang, Yang Z @ 2014-11-11 15:45 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 11+ messages in thread From: Konrad Rzeszutek Wilk @ 2014-11-11 15:45 UTC (permalink / raw) 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 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 <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! > > OK. We will provide a patch ASAP. Excellent. Looking forward to it! > > Best regards, > Yang > > ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-11-11 15:46 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2014-11-11 3:30 ` Zhang, Yang Z 2014-11-11 15:45 ` Konrad Rzeszutek Wilk
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.