[PATCH] XEN_DOMAIN_MEMORY options.

[PATCH] XEN_DOMAIN_MEMORY options.

[Maxim Uvarov]

Hello,

Please find here patches for XEN_MAX_DOMAIN_MEMORY:

[PATCH 1/2] xen: Fix XEN_MAX_DOMAIN_MEMORY to be selectable
[PATCH 2/2] xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible defaults for 32-bit builds

Best regards,
Maxim Uvarov.

[PATCH 1/2] xen: Fix XEN_MAX_DOMAIN_MEMORY to be selectable

[Maxim Uvarov]

The 'int' parameter also needs a description. Otherwise
it cannot be selected by the user.

Signed-off-by: Maxim Uvarov <maxim.uvarov@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 7cbcbd1..0b452c7 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -28,7 +28,7 @@ config XEN_PVHVM
 	depends on XEN && PCI && X86_LOCAL_APIC
 
 config XEN_MAX_DOMAIN_MEMORY
-       int
+       int "Maximum allowed size of a domain in gigabytes"
        default 128
        depends on XEN
        help
-- 
1.7.4.1

[PATCH 2/2] xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible defaults for 32-bit builds

[Maxim Uvarov]

Which is that 128GB is not going to happen with 32-bit PV DomU.
Lets use something more realistic.

Signed-off-by: Maxim Uvarov <maxim.uvarov@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/Kconfig |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 0b452c7..6d90ac8 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -29,7 +29,8 @@ config XEN_PVHVM
 
 config XEN_MAX_DOMAIN_MEMORY
        int "Maximum allowed size of a domain in gigabytes"
-       default 128
+       default 128 if X86_64
+       default 64 if X86_32
        depends on XEN
        help
          This only affects the sizing of some bss arrays, the unused
-- 
1.7.4.1

Re: [PATCH] XEN_DOMAIN_MEMORY options.

[Jeremy Fitzhardinge]

On 10/14/2011 03:36 PM, Maxim Uvarov wrote:
> Hello,
>
> Please find here patches for XEN_MAX_DOMAIN_MEMORY:
>
> [PATCH 1/2] xen: Fix XEN_MAX_DOMAIN_MEMORY to be selectable
> [PATCH 2/2] xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible defaults for 32-bit builds

What's the rationale?

    J

Re: [PATCH] XEN_DOMAIN_MEMORY options.

[Maxim Uvarov]

On 10/14/2011 04:00 PM, Jeremy Fitzhardinge wrote:
> On 10/14/2011 03:36 PM, Maxim Uvarov wrote:
>> Hello,
>>
>> Please find here patches for XEN_MAX_DOMAIN_MEMORY:
>>
>> [PATCH 1/2] xen: Fix XEN_MAX_DOMAIN_MEMORY to be selectable
>> [PATCH 2/2] xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible defaults for 32-bit builds
>
> What's the rationale?
>
>      J

The first patch is actually bug fix. You can not define just "int" 
without description in Kconfig. As the result this option will not be 
visible in menuconfig. Even if you will change it in .config make 
oldconfig will set it up for default value. So you need to add any 
description to it as all others int options have.

Second patch is more optional and it's just suggestion to use for 32 bit 
more corresponding value.

Maxim.

Re: [PATCH] XEN_DOMAIN_MEMORY options.

[Jeremy Fitzhardinge]

On 10/14/2011 04:33 PM, Maxim Uvarov wrote:
> On 10/14/2011 04:00 PM, Jeremy Fitzhardinge wrote:
>> On 10/14/2011 03:36 PM, Maxim Uvarov wrote:
>>> Hello,
>>>
>>> Please find here patches for XEN_MAX_DOMAIN_MEMORY:
>>>
>>> [PATCH 1/2] xen: Fix XEN_MAX_DOMAIN_MEMORY to be selectable
>>> [PATCH 2/2] xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible
>>> defaults for 32-bit builds
>>
>> What's the rationale?
>>
>>      J
>
> The first patch is actually bug fix. You can not define just "int"
> without description in Kconfig. As the result this option will not be
> visible in menuconfig. Even if you will change it in .config make
> oldconfig will set it up for default value. So you need to add any
> description to it as all others int options have.

No, that was deliberate, because I don't really think there's a need to
change it.

>
> Second patch is more optional and it's just suggestion to use for 32
> bit more corresponding value.

While it would be very silly to put 128GB of actual RAM on a 32-bit
machine, systems can have non-contiguous RAM placed at high addresses,
which would no longer be accessible.

    J

Re: [PATCH] XEN_DOMAIN_MEMORY options.

[Maxim Uvarov]

On 10/14/2011 04:41 PM, Jeremy Fitzhardinge wrote:
> On 10/14/2011 04:33 PM, Maxim Uvarov wrote:
>> On 10/14/2011 04:00 PM, Jeremy Fitzhardinge wrote:
>>> On 10/14/2011 03:36 PM, Maxim Uvarov wrote:
>>>> Hello,
>>>>
>>>> Please find here patches for XEN_MAX_DOMAIN_MEMORY:
>>>>
>>>> [PATCH 1/2] xen: Fix XEN_MAX_DOMAIN_MEMORY to be selectable
>>>> [PATCH 2/2] xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible
>>>> defaults for 32-bit builds
>>>
>>> What's the rationale?
>>>
>>>       J
>>
>> The first patch is actually bug fix. You can not define just "int"
>> without description in Kconfig. As the result this option will not be
>> visible in menuconfig. Even if you will change it in .config make
>> oldconfig will set it up for default value. So you need to add any
>> description to it as all others int options have.
>
> No, that was deliberate, because I don't really think there's a need to
> change it.
>

 From that point of view it's not clear why this option is still in Kconfig?

Jeremy, can you please share more details about this? I see people are 
having troubles with this option and in different kernels I see 
different work arounds  for it. For example:
http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01841.html

Maxim.
>>
>> Second patch is more optional and it's just suggestion to use for 32
>> bit more corresponding value.
>
> While it would be very silly to put 128GB of actual RAM on a 32-bit
> machine, systems can have non-contiguous RAM placed at high addresses,
> which would no longer be accessible.
>
>      J

Re: [PATCH] XEN_DOMAIN_MEMORY options.

[Konrad Rzeszutek Wilk]

On Fri, Oct 14, 2011 at 05:43:37PM -0700, Maxim Uvarov wrote:
> On 10/14/2011 04:41 PM, Jeremy Fitzhardinge wrote:
> >On 10/14/2011 04:33 PM, Maxim Uvarov wrote:
> >>On 10/14/2011 04:00 PM, Jeremy Fitzhardinge wrote:
> >>>On 10/14/2011 03:36 PM, Maxim Uvarov wrote:
> >>>>Hello,
> >>>>
> >>>>Please find here patches for XEN_MAX_DOMAIN_MEMORY:
> >>>>
> >>>>[PATCH 1/2] xen: Fix XEN_MAX_DOMAIN_MEMORY to be selectable
> >>>>[PATCH 2/2] xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible
> >>>>defaults for 32-bit builds
> >>>
> >>>What's the rationale?
> >>>
> >>>      J
> >>
> >>The first patch is actually bug fix. You can not define just "int"
> >>without description in Kconfig. As the result this option will not be
> >>visible in menuconfig. Even if you will change it in .config make
> >>oldconfig will set it up for default value. So you need to add any
> >>description to it as all others int options have.
> >
> >No, that was deliberate, because I don't really think there's a need to
> >change it.
> >
> 
> From that point of view it's not clear why this option is still in Kconfig?

Well, we do need to alter it to 512GB. Actually -  putting that extra
burden on initial pagetables to reserve extra 384 pages might be a bit
too much. Even thought later on we reclaim it if we do not use it.

Either way, we should be able to boot a PV guest with 512GB, so why not
just make that the default for 64-bit?
> 
> Jeremy, can you please share more details about this? I see people are 
> having troubles with this option and in different kernels I see 
> different work arounds  for it. For example:
> http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01841.html

.. which ultimately was due to bugs in the initial page tables setup in
the generic code and in the Xen MMU (fixed in 2.6.39):

279b706 x86,xen: introduce x86_init.mapping.pagetable_reserve
b9269dc xen: mask_rw_pte mark RO all pagetable pages up to pgt_buf_top
ee17645 xen: mask_rw_pte: do not apply the early_ioremap checks on x86_32
d8aa5ec xen: update mask_rw_pte after kernel page tables init changes
e5f15b4 x86: Cleanup highmap after brk is conclude

What are the "I see people are having troubles with this option" ?
(Anything before 2.6.39 is very much related to those bug-fixes I
just pointed out).

> 
> Maxim.
> >>
> >>Second patch is more optional and it's just suggestion to use for 32
> >>bit more corresponding value.
> >
> >While it would be very silly to put 128GB of actual RAM on a 32-bit
> >machine, systems can have non-contiguous RAM placed at high addresses,
> >which would no longer be accessible.

Do you have some ideas of which machines that might be?

Re: [PATCH] XEN_DOMAIN_MEMORY options.

[Ian Campbell]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Sat, 2011-10-15 at 09:05 -0400, Konrad Rzeszutek Wilk wrote:
> > On 10/14/2011 04:41 PM, Jeremy Fitzhardinge wrote:

> > >While it would be very silly to put 128GB of actual RAM on a 32-bit
> > >machine, systems can have non-contiguous RAM placed at high addresses,
> > >which would no longer be accessible.
> 
> Do you have some ideas of which machines that might be?

Even if you were on such a machine, the discontiguity
(discontiguousness?) wouldn't ever be reflected in the pseudo-physical
memory map, would it? So since this variable controls the maximum size
of the p2m (rather than the m2p) it doesn't need to be larger than the
maximum sane 32 bit guest size (<64G).

Ian.
-- 
Ian Campbell


Every improvement in communication makes the bore more terrible.
		-- Frank Moore Colby

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Xen-devel] Re: [PATCH] XEN_DOMAIN_MEMORY options.

[Konrad Rzeszutek Wilk]

On Sat, Oct 15, 2011 at 05:42:48PM +0100, Ian Campbell wrote:
> On Sat, 2011-10-15 at 09:05 -0400, Konrad Rzeszutek Wilk wrote:
> > > On 10/14/2011 04:41 PM, Jeremy Fitzhardinge wrote:
> 
> > > >While it would be very silly to put 128GB of actual RAM on a 32-bit
> > > >machine, systems can have non-contiguous RAM placed at high addresses,
> > > >which would no longer be accessible.
> > 
> > Do you have some ideas of which machines that might be?
> 
> Even if you were on such a machine, the discontiguity
> (discontiguousness?) wouldn't ever be reflected in the pseudo-physical
> memory map, would it? So since this variable controls the maximum size
> of the p2m (rather than the m2p) it doesn't need to be larger than the
> maximum sane 32 bit guest size (<64G).

I think it is the other way around. The M2P would not be affected but
the P2M might? The "discontinuity" is in the E820 right? (so mega big
holes in it).

Re: [PATCH] XEN_DOMAIN_MEMORY options.

[Konrad Rzeszutek Wilk]

> > >>>What's the rationale?
> > >>>
> > >>>      J
> > >>
> > >>The first patch is actually bug fix. You can not define just "int"
> > >>without description in Kconfig. As the result this option will not be
> > >>visible in menuconfig. Even if you will change it in .config make
> > >>oldconfig will set it up for default value. So you need to add any
> > >>description to it as all others int options have.
> > >
> > >No, that was deliberate, because I don't really think there's a need to
> > >change it.
> > >
> > 
> > From that point of view it's not clear why this option is still in Kconfig?
> 
> Well, we do need to alter it to 512GB. Actually -  putting that extra
> burden on initial pagetables to reserve extra 384 pages might be a bit
> too much. Even thought later on we reclaim it if we do not use it.

Jeremy, without that change, you cannot specify

CONFIG_XEN_MAX_DOMAIN_MEMORY=512

if the distro desires to do so. Well, you can write it in the .config,
but the moment you compile, the oldconfig rewrites it to 128.