WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel