[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Liang Li]

If hardware support the pdpe1gb flag, expose it to guest by default.
Users don't have to use a 'cpuid= ' option in config file to turn
it on.

Signed-off-by: Liang Li <liang.z.li@intel.com>
---
 tools/libxc/xc_cpuid_x86.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index a18b1ff..c97f91a 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy(
         regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */
                     bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_MP) |
                     bitmaskof(X86_FEATURE_MMXEXT) |
@@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_ABM));
         regs[3] &= (bitmaskof(X86_FEATURE_NX) |
                     bitmaskof(X86_FEATURE_LM) |
+                    bitmaskof(X86_FEATURE_PAGE1GB) |
                     bitmaskof(X86_FEATURE_SYSCALL) |
                     bitmaskof(X86_FEATURE_RDTSCP));
         break;
@@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy(
             clear_bit(X86_FEATURE_LM, regs[3]);
             clear_bit(X86_FEATURE_NX, regs[3]);
             clear_bit(X86_FEATURE_PSE36, regs[3]);
+            clear_bit(X86_FEATURE_PAGE1GB, regs[3]);
         }
         break;
 
-- 
1.9.1

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Ian Jackson]

Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> If hardware support the pdpe1gb flag, expose it to guest by default.
> Users don't have to use a 'cpuid= ' option in config file to turn
> it on.

I don't understand what this flag does.  I guess from the name it
turns on 1G pages.  I guess these are supported ?

I would like to see comment from an x86 hypervisor maintainer.

Thanks,
Ian.

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Jan Beulich]

>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>> If hardware support the pdpe1gb flag, expose it to guest by default.
>> Users don't have to use a 'cpuid= ' option in config file to turn
>> it on.
> 
> I don't understand what this flag does.  I guess from the name it
> turns on 1G pages.  I guess these are supported ?
> 
> I would like to see comment from an x86 hypervisor maintainer.

Yes, we support 1Gb pages. The purpose of the patch is to not
unconditionally hide the flag from guests. (I had commented on
v1, but sadly this one wasn't tagged as v2, nor was I included on
the Cc list, hence I didn't spot the new version.)

The one thing I'm not certain about is shadow mode: Only 2Mb
pages may be supported there. Tim?

Jan

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Tim Deegan]

At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
> >>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> > Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >> If hardware support the pdpe1gb flag, expose it to guest by default.
> >> Users don't have to use a 'cpuid= ' option in config file to turn
> >> it on.
> > 
> > I don't understand what this flag does.  I guess from the name it
> > turns on 1G pages.  I guess these are supported ?
> > 
> > I would like to see comment from an x86 hypervisor maintainer.
> 
> Yes, we support 1Gb pages. The purpose of the patch is to not
> unconditionally hide the flag from guests. (I had commented on
> v1, but sadly this one wasn't tagged as v2, nor was I included on
> the Cc list, hence I didn't spot the new version.)
> 
> The one thing I'm not certain about is shadow mode: Only 2Mb
> pages may be supported there. Tim?

Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()

Tim.

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Andrew Cooper]

On 17/11/14 16:30, Tim Deegan wrote:
> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>> Users don't have to use a 'cpuid= ' option in config file to turn
>>>> it on.
>>> I don't understand what this flag does.  I guess from the name it
>>> turns on 1G pages.  I guess these are supported ?
>>>
>>> I would like to see comment from an x86 hypervisor maintainer.
>> Yes, we support 1Gb pages. The purpose of the patch is to not
>> unconditionally hide the flag from guests. (I had commented on
>> v1, but sadly this one wasn't tagged as v2, nor was I included on
>> the Cc list, hence I didn't spot the new version.)
>>
>> The one thing I'm not certain about is shadow mode: Only 2Mb
>> pages may be supported there. Tim?
> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()

This is yet another case which proves that libxc is the wrong place to
be choosing the cpuid flags exposed to a domain.

Furthermore, guest_supports_1G_superpages() is insufficient as it only
checks whether the host is capable of providing 1G superpages, not
whether the guest has been permitted to use it.

This causes a problem when migrating between hap-capable and
hap-incapable systems.

I do hope to fix all of this with my planned changes to the cpuid
infrastructure.

~Andrew

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Tim Deegan]

At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
> On 17/11/14 16:30, Tim Deegan wrote:
> > At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
> >>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> >>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >>>> If hardware support the pdpe1gb flag, expose it to guest by default.
> >>>> Users don't have to use a 'cpuid= ' option in config file to turn
> >>>> it on.
> >>> I don't understand what this flag does.  I guess from the name it
> >>> turns on 1G pages.  I guess these are supported ?
> >>>
> >>> I would like to see comment from an x86 hypervisor maintainer.
> >> Yes, we support 1Gb pages. The purpose of the patch is to not
> >> unconditionally hide the flag from guests. (I had commented on
> >> v1, but sadly this one wasn't tagged as v2, nor was I included on
> >> the Cc list, hence I didn't spot the new version.)
> >>
> >> The one thing I'm not certain about is shadow mode: Only 2Mb
> >> pages may be supported there. Tim?
> > Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
> > guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
> 
> This is yet another case which proves that libxc is the wrong place to
> be choosing the cpuid flags exposed to a domain.
> 
> Furthermore, guest_supports_1G_superpages() is insufficient as it only
> checks whether the host is capable of providing 1G superpages, not
> whether the guest has been permitted to use it.
> 
> This causes a problem when migrating between hap-capable and
> hap-incapable systems.

There's no notion of 'permitted' to use 1G pages, AFAICS, much like
other CPU features.  But of course a _well-behaved_ guest that has
been told in cpuid not to use 1G superpages will have no problems. :)

> I do hope to fix all of this with my planned changes to the cpuid
> infrastructure.

Good luck!

Tim.

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Andrew Cooper]

On 17/11/14 17:00, Tim Deegan wrote:
> At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
>> On 17/11/14 16:30, Tim Deegan wrote:
>>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>>>> Users don't have to use a 'cpuid= ' option in config file to turn
>>>>>> it on.
>>>>> I don't understand what this flag does.  I guess from the name it
>>>>> turns on 1G pages.  I guess these are supported ?
>>>>>
>>>>> I would like to see comment from an x86 hypervisor maintainer.
>>>> Yes, we support 1Gb pages. The purpose of the patch is to not
>>>> unconditionally hide the flag from guests. (I had commented on
>>>> v1, but sadly this one wasn't tagged as v2, nor was I included on
>>>> the Cc list, hence I didn't spot the new version.)
>>>>
>>>> The one thing I'm not certain about is shadow mode: Only 2Mb
>>>> pages may be supported there. Tim?
>>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
>>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
>> This is yet another case which proves that libxc is the wrong place to
>> be choosing the cpuid flags exposed to a domain.
>>
>> Furthermore, guest_supports_1G_superpages() is insufficient as it only
>> checks whether the host is capable of providing 1G superpages, not
>> whether the guest has been permitted to use it.
>>
>> This causes a problem when migrating between hap-capable and
>> hap-incapable systems.
> There's no notion of 'permitted' to use 1G pages, AFAICS, much like
> other CPU features.  But of course a _well-behaved_ guest that has
> been told in cpuid not to use 1G superpages will have no problems. :)

That is my point.

If 1GB pages are not supported (i.e. not present in cpuid), then the PS
bit in an L3 is reserved, must be 0, and cause a pagefault if used.

Nothing in Xen currently enforces this because
guest_supports_1G_superpages() doesn't check domain_cpuid().

It does however make me wonder how VMX/SVM non-root mode would enforce
this as it would see the host cpuid, not guest cpuid when performing
paging internally.

~Andrew

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Tim Deegan]

At 17:25 +0000 on 17 Nov (1416241517), Andrew Cooper wrote:
> On 17/11/14 17:00, Tim Deegan wrote:
> > At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
> >> On 17/11/14 16:30, Tim Deegan wrote:
> >>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
> >>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
> >>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
> >>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
> >>>>>> Users don't have to use a 'cpuid= ' option in config file to turn
> >>>>>> it on.
> >>>>> I don't understand what this flag does.  I guess from the name it
> >>>>> turns on 1G pages.  I guess these are supported ?
> >>>>>
> >>>>> I would like to see comment from an x86 hypervisor maintainer.
> >>>> Yes, we support 1Gb pages. The purpose of the patch is to not
> >>>> unconditionally hide the flag from guests. (I had commented on
> >>>> v1, but sadly this one wasn't tagged as v2, nor was I included on
> >>>> the Cc list, hence I didn't spot the new version.)
> >>>>
> >>>> The one thing I'm not certain about is shadow mode: Only 2Mb
> >>>> pages may be supported there. Tim?
> >>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
> >>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
> >> This is yet another case which proves that libxc is the wrong place to
> >> be choosing the cpuid flags exposed to a domain.
> >>
> >> Furthermore, guest_supports_1G_superpages() is insufficient as it only
> >> checks whether the host is capable of providing 1G superpages, not
> >> whether the guest has been permitted to use it.
> >>
> >> This causes a problem when migrating between hap-capable and
> >> hap-incapable systems.
> > There's no notion of 'permitted' to use 1G pages, AFAICS, much like
> > other CPU features.  But of course a _well-behaved_ guest that has
> > been told in cpuid not to use 1G superpages will have no problems. :)
> 
> That is my point.
> 
> If 1GB pages are not supported (i.e. not present in cpuid), then the PS
> bit in an L3 is reserved, must be 0, and cause a pagefault if used.
> 
> Nothing in Xen currently enforces this because
> guest_supports_1G_superpages() doesn't check domain_cpuid().

For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
HVM cpuid handler, so we don't advertise a feature we can't support.

For HAP mode, we _could_ add a cpuid check to the pagetable walker
but...

> It does however make me wonder how VMX/SVM non-root mode would enforce
> this as it would see the host cpuid, not guest cpuid when performing
> paging internally.

...non-emulated PT walks will get to use 1GB superpages anyway.
This is the same for other features (new instructions &c).  We
can mask them out of CPUID but by and large we can't make them fault.

Tim.

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Andrew Cooper]

On 18/11/14 10:14, Tim Deegan wrote:
> At 17:25 +0000 on 17 Nov (1416241517), Andrew Cooper wrote:
>> On 17/11/14 17:00, Tim Deegan wrote:
>>> At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
>>>> On 17/11/14 16:30, Tim Deegan wrote:
>>>>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag to guest"):
>>>>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>>>>>> Users don't have to use a 'cpuid= ' option in config file to turn
>>>>>>>> it on.
>>>>>>> I don't understand what this flag does.  I guess from the name it
>>>>>>> turns on 1G pages.  I guess these are supported ?
>>>>>>>
>>>>>>> I would like to see comment from an x86 hypervisor maintainer.
>>>>>> Yes, we support 1Gb pages. The purpose of the patch is to not
>>>>>> unconditionally hide the flag from guests. (I had commented on
>>>>>> v1, but sadly this one wasn't tagged as v2, nor was I included on
>>>>>> the Cc list, hence I didn't spot the new version.)
>>>>>>
>>>>>> The one thing I'm not certain about is shadow mode: Only 2Mb
>>>>>> pages may be supported there. Tim?
>>>>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
>>>>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mode_hap()
>>>> This is yet another case which proves that libxc is the wrong place to
>>>> be choosing the cpuid flags exposed to a domain.
>>>>
>>>> Furthermore, guest_supports_1G_superpages() is insufficient as it only
>>>> checks whether the host is capable of providing 1G superpages, not
>>>> whether the guest has been permitted to use it.
>>>>
>>>> This causes a problem when migrating between hap-capable and
>>>> hap-incapable systems.
>>> There's no notion of 'permitted' to use 1G pages, AFAICS, much like
>>> other CPU features.  But of course a _well-behaved_ guest that has
>>> been told in cpuid not to use 1G superpages will have no problems. :)
>> That is my point.
>>
>> If 1GB pages are not supported (i.e. not present in cpuid), then the PS
>> bit in an L3 is reserved, must be 0, and cause a pagefault if used.
>>
>> Nothing in Xen currently enforces this because
>> guest_supports_1G_superpages() doesn't check domain_cpuid().
> For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
> HVM cpuid handler, so we don't advertise a feature we can't support.
>
> For HAP mode, we _could_ add a cpuid check to the pagetable walker
> but...
>
>> It does however make me wonder how VMX/SVM non-root mode would enforce
>> this as it would see the host cpuid, not guest cpuid when performing
>> paging internally.
> ...non-emulated PT walks will get to use 1GB superpages anyway.
> This is the same for other features (new instructions &c).  We
> can mask them out of CPUID but by and large we can't make them fault.

Hmm - this is a pitfall waiting to happen.

In the case that there is a heterogeneous setup with one 1G capable and
one 1G incapable server, Xen cannot forcibly prevent the use of 1G pages
on the capable hardware.  Any VM which guesses at hardware support by
means other than cpuid features is liable to explode on migrate.

I suspect this will just have to fall into the category of "here be yet
more dragons with heterogeneous migration"

~Andrew

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Zhang, Yang Z]

Andrew Cooper wrote on 2014-11-18:
> On 18/11/14 10:14, Tim Deegan wrote:
>> At 17:25 +0000 on 17 Nov (1416241517), Andrew Cooper wrote:
>>> On 17/11/14 17:00, Tim Deegan wrote:
>>>> At 16:40 +0000 on 17 Nov (1416238835), Andrew Cooper wrote:
>>>>> On 17/11/14 16:30, Tim Deegan wrote:
>>>>>> At 16:24 +0000 on 17 Nov (1416237888), Jan Beulich wrote:
>>>>>>>>>> On 17.11.14 at 16:39, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>>>> Liang Li writes ("[PATCH] libxc: Expose the pdpe1gb cpuid flag
>>>>>>>> to
> guest"):
>>>>>>>>> If hardware support the pdpe1gb flag, expose it to guest by default.
>>>>>>>>> Users don't have to use a 'cpuid= ' option in config file to
>>>>>>>>> turn it on.
>>>>>>>> I don't understand what this flag does.  I guess from the name
>>>>>>>> it turns on 1G pages.  I guess these are supported ?
>>>>>>>> 
>>>>>>>> I would like to see comment from an x86 hypervisor maintainer.
>>>>>>> Yes, we support 1Gb pages. The purpose of the patch is to not
>>>>>>> unconditionally hide the flag from guests. (I had commented on
>>>>>>> v1, but sadly this one wasn't tagged as v2, nor was I included
>>>>>>> on the Cc list, hence I didn't spot the new version.)
>>>>>>> 
>>>>>>> The one thing I'm not certain about is shadow mode: Only 2Mb
>>>>>>> pages may be supported there. Tim?
>>>>>> Indeed, only 2MiB pages are supported in shadow mode.  See, e.g.
>>>>>> 
>>>>>> guest_supports_1G_superpages()->hvm_pse1gb_supported()->paging_mod
>>>>>> e_hap()
>>>>> This is yet another case which proves that libxc is the wrong
>>>>> place to be choosing the cpuid flags exposed to a domain.
>>>>> 
>>>>> Furthermore, guest_supports_1G_superpages() is insufficient as it
>>>>> only checks whether the host is capable of providing 1G
>>>>> superpages, not whether the guest has been permitted to use it.
>>>>> 
>>>>> This causes a problem when migrating between hap-capable and
>>>>> hap-incapable systems.
>>>> There's no notion of 'permitted' to use 1G pages, AFAICS, much
>>>> like other CPU features.  But of course a _well-behaved_ guest
>>>> that has been told in cpuid not to use 1G superpages will have no problems.
>>>> :)
>>> That is my point.
>>> 
>>> If 1GB pages are not supported (i.e. not present in cpuid), then
>>> the PS bit in an L3 is reserved, must be 0, and cause a pagefault if used.
>>> 
>>> Nothing in Xen currently enforces this because
>>> guest_supports_1G_superpages() doesn't check domain_cpuid().
>> For shadow mode, Xen DTRT by checking hvm_pse1gb_supported() in the
>> HVM cpuid handler, so we don't advertise a feature we can't support.
>> 
>> For HAP mode, we _could_ add a cpuid check to the pagetable walker
>> but...
>> 
>>> It does however make me wonder how VMX/SVM non-root mode would
>>> enforce this as it would see the host cpuid, not guest cpuid when
>>> performing paging internally.
>> ...non-emulated PT walks will get to use 1GB superpages anyway.
>> This is the same for other features (new instructions &c).  We can
>> mask them out of CPUID but by and large we can't make them fault.

Agree. I will forward this question to internally to see whether they aware of this problem.

> 
> Hmm - this is a pitfall waiting to happen.
> 
> In the case that there is a heterogeneous setup with one 1G capable
> and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
> pages on the capable hardware.  Any VM which guesses at hardware
> support by means other than cpuid features is liable to explode on migrate.

But a normal guest shouldn't to guess it, right?

> 
> I suspect this will just have to fall into the category of "here be
> yet more dragons with heterogeneous migration"
> 
> ~Andrew


Best regards,
Yang

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Ian Campbell]

On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
> > Hmm - this is a pitfall waiting to happen.
> > 
> > In the case that there is a heterogeneous setup with one 1G capable
> > and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
> > pages on the capable hardware.  Any VM which guesses at hardware
> > support by means other than cpuid features is liable to explode on migrate.
> 
> But a normal guest shouldn't to guess it, right?

IMHO any guest which does not use the mechanism explicitly provided for
feature detection deserves to break randomly.

It's basically equivalent to a physical system where the BIOS masks this
cpuid bit because of some hardware errata or something, the underlying
feature might appear to be present but will have more or less subtle
issues.

Ian.

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Tim Deegan]

At 14:26 +0000 on 18 Nov (1416317209), Ian Campbell wrote:
> On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
> > > Hmm - this is a pitfall waiting to happen.
> > > 
> > > In the case that there is a heterogeneous setup with one 1G capable
> > > and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
> > > pages on the capable hardware.  Any VM which guesses at hardware
> > > support by means other than cpuid features is liable to explode on migrate.
> > 
> > But a normal guest shouldn't to guess it, right?
> 
> IMHO any guest which does not use the mechanism explicitly provided for
> feature detection deserves to break randomly.

Yes, that's a reasonable position (notwithstanding that we know such
software exists).

In this case, the guest is entitled to _expect_ pagefaults on 1GB
mappings if CPUID claims they are not supported.  That sounds like an
unlikely thing for the guest to be relying on, but Xen itself does
something similar for the SHOPT_FAST_FAULT_PATH (and now also for
IOMMU entries for the deferred caching attribute updates).

Cheers,

Tim.

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Zhang, Yang Z]

Tim Deegan wrote on 2014-11-18:
> At 14:26 +0000 on 18 Nov (1416317209), Ian Campbell wrote:
>> On Tue, 2014-11-18 at 11:41 +0000, Zhang, Yang Z wrote:
>>>> Hmm - this is a pitfall waiting to happen.
>>>> 
>>>> In the case that there is a heterogeneous setup with one 1G
>>>> capable and one 1G incapable server, Xen cannot forcibly prevent
>>>> the use of 1G pages on the capable hardware.  Any VM which
>>>> guesses at hardware support by means other than cpuid features
>>>> is liable to
> explode on migrate.
>>> 
>>> But a normal guest shouldn't to guess it, right?
>> 
>> IMHO any guest which does not use the mechanism explicitly provided
>> for feature detection deserves to break randomly.
> 
> Yes, that's a reasonable position (notwithstanding that we know such
> software exists).
> 

Agree.

> In this case, the guest is entitled to _expect_ pagefaults on 1GB
> mappings if CPUID claims they are not supported.  That sounds like an
> unlikely thing for the guest to be relying on, but Xen itself does
> something similar for the SHOPT_FAST_FAULT_PATH (and now also for
> IOMMU entries for the deferred caching attribute updates).

Indeed. How about adding the software check (as Andrew mentioned) firstly and leave the hardware problem (Actually, I don't think we can solve it currently).

> 
> Cheers,
> 
> Tim.


Best regards,
Yang

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Tim Deegan]

At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
> Tim Deegan wrote on 2014-11-18:
> > In this case, the guest is entitled to _expect_ pagefaults on 1GB
> > mappings if CPUID claims they are not supported.  That sounds like an
> > unlikely thing for the guest to be relying on, but Xen itself does
> > something similar for the SHOPT_FAST_FAULT_PATH (and now also for
> > IOMMU entries for the deferred caching attribute updates).
> 
> Indeed. How about adding the software check (as Andrew mentioned)
> firstly and leave the hardware problem (Actually, I don't think we
> can solve it currently).

I don't think we should change the software path unless we can change
the hardware behaviour too.  It's better to be consistent, and it
saves us some cycles in the pt walker.

Cheers,

Tim.

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Zhang, Yang Z]

Tim Deegan wrote on 2014-11-19:
> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>> Tim Deegan wrote on 2014-11-18:
>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>> mappings if CPUID claims they are not supported.  That sounds like
>>> an unlikely thing for the guest to be relying on, but Xen itself
>>> does something similar for the SHOPT_FAST_FAULT_PATH (and now also
>>> for IOMMU entries for the deferred caching attribute updates).
>> 
>> Indeed. How about adding the software check (as Andrew mentioned)
>> firstly and leave the hardware problem (Actually, I don't think we
>> can solve it currently).
> 
> I don't think we should change the software path unless we can change
> the hardware behaviour too.  It's better to be consistent, and it
> saves us some cycles in the pt walker.

So if we don't need to add the software check, does this mean current patch is ok?

> 
> Cheers,
> 
> Tim.


Best regards,
Yang

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Jan Beulich]

>>> On 25.11.14 at 02:47, <yang.z.zhang@intel.com> wrote:
> Tim Deegan wrote on 2014-11-19:
>> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>>> Tim Deegan wrote on 2014-11-18:
>>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>>> mappings if CPUID claims they are not supported.  That sounds like
>>>> an unlikely thing for the guest to be relying on, but Xen itself
>>>> does something similar for the SHOPT_FAST_FAULT_PATH (and now also
>>>> for IOMMU entries for the deferred caching attribute updates).
>>> 
>>> Indeed. How about adding the software check (as Andrew mentioned)
>>> firstly and leave the hardware problem (Actually, I don't think we
>>> can solve it currently).
>> 
>> I don't think we should change the software path unless we can change
>> the hardware behaviour too.  It's better to be consistent, and it
>> saves us some cycles in the pt walker.
> 
> So if we don't need to add the software check, does this mean current patch 
> is ok?

No - Tim having confirmed that shadow mode doesn't support 1Gb
pages, the feature clearly must not be made visible for shadow
mode guest.

Jan

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Zhang, Yang Z]

Jan Beulich wrote on 2014-11-25:
>>>> On 25.11.14 at 02:47, <yang.z.zhang@intel.com> wrote:
>> Tim Deegan wrote on 2014-11-19:
>>> At 01:29 +0000 on 19 Nov (1416356943), Zhang, Yang Z wrote:
>>>> Tim Deegan wrote on 2014-11-18:
>>>>> In this case, the guest is entitled to _expect_ pagefaults on 1GB
>>>>> mappings if CPUID claims they are not supported.  That sounds
>>>>> like an unlikely thing for the guest to be relying on, but Xen
>>>>> itself does something similar for the SHOPT_FAST_FAULT_PATH (and
>>>>> now also for IOMMU entries for the deferred caching attribute updates).
>>>> 
>>>> Indeed. How about adding the software check (as Andrew mentioned)
>>>> firstly and leave the hardware problem (Actually, I don't think we
>>>> can solve it currently).
>>> 
>>> I don't think we should change the software path unless we can
>>> change the hardware behaviour too.  It's better to be consistent,
>>> and it saves us some cycles in the pt walker.
>> 
>> So if we don't need to add the software check, does this mean
>> current patch is ok?
> 
> No - Tim having confirmed that shadow mode doesn't support 1Gb pages,
> the feature clearly must not be made visible for shadow mode guest.

Indeed. Liang, Can you add the shadow mode check in the next version?

> 
> Jan


Best regards,
Yang

Re: [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest

[Li, Liang Z]

>>> patch is ok?
>> 
>> No - Tim having confirmed that shadow mode doesn't support 1Gb pages, 
> the feature clearly must not be made visible for shadow mode guest.

>Indeed. Liang, Can you add the shadow mode check in the next version?

Ok , I will do it and resend the patch.