1GB hugepages and intel_xc_cpuid_policy by default disables it.

1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Konrad Rzeszutek Wilk]

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!

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Ian Campbell]

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.

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Jan Beulich]

>>> 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

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Ian Campbell]

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.

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Jan Beulich]

>>> 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

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Konrad Rzeszutek Wilk]

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
> 

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Jan Beulich]

>>> 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

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Zhang, Yang Z]

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

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Konrad Rzeszutek Wilk]

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!

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Zhang, Yang Z]

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

Re: 1GB hugepages and intel_xc_cpuid_policy by default disables it.

[Konrad Rzeszutek Wilk]

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
> 
>