linux-kernel - Re: [Xen-devel] [PATCH 07/10] xen/mmu: Work with 1-1 mappings when allocating new top/middle entries.

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: <1293008071.3998.41.camel@localhost.localdomain>
Date:	Wed, 22 Dec 2010 08:54:31 +0000
From:	Ian Campbell <Ian.Campbell@...rix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jeremy@...p.org" <jeremy@...p.org>,
	"hpa@...or.com" <hpa@...or.com>,
	Konrad Rzeszutek Wilk <konrad@...nel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Jan Beulich <JBeulich@...ell.com>
Subject: Re: [Xen-devel] [PATCH 07/10] xen/mmu: Work with 1-1 mappings when
 allocating new top/middle entries.

On Tue, 2010-12-21 at 21:37 +0000, Konrad Rzeszutek Wilk wrote: 
> We were not properly taking under advisement the 1-1 mappings
> when a large area of memory was ballooned out.

Are we lazily allocating the p2m tree nodes for regions initially
covered by the balloon? (perhaps we have always done this and it isn't
new with this series)

Would it be simpley to always populate enough tree nodes to cover the
ballooned area as well as nr_pages at start of day and therefore avoid
worrying about it later on (except for memory hotplug which is special
in this way already)?

Ian.

> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> ---
>  arch/x86/xen/mmu.c |   13 ++++++++-----
>  1 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index bd02e7d..92f4fec 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -464,7 +464,7 @@ static void free_p2m_page(void *p)
>  static bool alloc_p2m(unsigned long pfn)
>  {
>  	unsigned topidx, mididx;
> -	unsigned long ***top_p, **mid;
> +	unsigned long ***top_p, **mid, **mid_orig;
>  	unsigned long *top_mfn_p, *mid_mfn;
>  
>  	topidx = p2m_top_index(pfn);
> @@ -473,15 +473,16 @@ static bool alloc_p2m(unsigned long pfn)
>  	top_p = &p2m_top[topidx];
>  	mid = *top_p;
>  
> -	if (mid == p2m_mid_identity) {
> +	if (mid == p2m_mid_identity || mid == p2m_mid_missing) {
>  		/* Mid level is missing, allocate a new one */
> +		mid_orig = mid;
>  		mid = alloc_p2m_page();
>  		if (!mid)
>  			return false;
>  
>  		p2m_mid_init(mid, p2m_identity);
>  
> -		if (cmpxchg(top_p, p2m_mid_identity, mid) != p2m_mid_identity)
> +		if (cmpxchg(top_p, mid_orig, mid) != mid_orig)
>  			free_p2m_page(mid);
>  	}
>  
> @@ -510,9 +511,11 @@ static bool alloc_p2m(unsigned long pfn)
>  			p2m_top_mfn_p[topidx] = mid_mfn;
>  	}
>  
> -	if (p2m_top[topidx][mididx] == p2m_identity) {
> +	if (p2m_top[topidx][mididx] == p2m_identity ||
> +	    p2m_top[topidx][mididx] == p2m_missing) {
>  		/* p2m leaf page is missing */
>  		unsigned long *p2m;
> +		unsigned long *p2m_orig = p2m_top[topidx][mididx];
>  
>  		p2m = alloc_p2m_page();
>  		if (!p2m)
> @@ -520,7 +523,7 @@ static bool alloc_p2m(unsigned long pfn)
>  
>  		p2m_init(p2m);
>  
> -		if (cmpxchg(&mid[mididx], p2m_identity, p2m) != p2m_identity)
> +		if (cmpxchg(&mid[mididx], p2m_orig, p2m) != p2m_orig)
>  			free_p2m_page(p2m);
>  		else
>  			mid_mfn[mididx] = virt_to_mfn(p2m);


--
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/