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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Maxim Uvarov
2011-Oct-14 22:36 UTC
[Xen-devel] [PATCH 1/2] xen: Fix XEN_MAX_DOMAIN_MEMORY to be selectable
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Maxim Uvarov
2011-Oct-14 22:36 UTC
[Xen-devel] [PATCH 2/2] xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible defaults for 32-bit builds
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2011-Oct-14 23:00 UTC
[Xen-devel] Re: [PATCH] XEN_DOMAIN_MEMORY options.
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 buildsWhat''s the rationale? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? > > JThe 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2011-Oct-14 23:41 UTC
[Xen-devel] Re: [PATCH] XEN_DOMAIN_MEMORY options.
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Oct-15 13:05 UTC
[Xen-devel] Re: [PATCH] XEN_DOMAIN_MEMORY options.
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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Oct-19 14:04 UTC
[Xen-devel] Re: [PATCH] XEN_DOMAIN_MEMORY options.
> > >>>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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Oct-19 14:05 UTC
Re: [Xen-devel] Re: [PATCH] XEN_DOMAIN_MEMORY options.
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). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel