Messages in this thread | | | Date | Sat, 15 Oct 2011 09:05:52 -0400 | From | Konrad Rzeszutek Wilk <> | Subject | 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?
| |