linux-kernel - Re: [PATCH] XEN_DOMAIN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111015130552.GC18864@andromeda.dapyr.net>
Date:	Sat, 15 Oct 2011 09:05:52 -0400
From:	Konrad Rzeszutek Wilk <konrad@...nok.org>
To:	Maxim Uvarov <maxim.uvarov@...cle.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org,
	konrad.wilk@...cle.com
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/