From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755034AbbDINJG (ORCPT ); Thu, 9 Apr 2015 09:09:06 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47439 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752960AbbDINJE (ORCPT ); Thu, 9 Apr 2015 09:09:04 -0400 Message-ID: <552679EE.1020704@suse.com> Date: Thu, 09 Apr 2015 15:09:02 +0200 From: Juergen Gross User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: David Vrabel , linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, david.vrabel@citrix.com, boris.ostrovsky@oracle.com, linux-mm@kvack.org Subject: Re: [Xen-devel] [Patch V2 10/15] xen: check pre-allocated page tables for conflict with memory map References: <1428562542-28488-1-git-send-email-jgross@suse.com> <1428562542-28488-11-git-send-email-jgross@suse.com> <552674C8.7010104@cantab.net> In-Reply-To: <552674C8.7010104@cantab.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/09/2015 02:47 PM, David Vrabel wrote: > On 09/04/2015 07:55, Juergen Gross wrote: >> Check whether the page tables built by the domain builder are at >> memory addresses which are in conflict with the target memory map. >> If this is the case just panic instead of running into problems >> later. >> >> Signed-off-by: Juergen Gross >> --- >> arch/x86/xen/mmu.c | 19 ++++++++++++++++--- >> arch/x86/xen/setup.c | 6 ++++++ >> arch/x86/xen/xen-ops.h | 1 + >> 3 files changed, 23 insertions(+), 3 deletions(-) >> >> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c >> index 1ca5197..41aeb1c 100644 >> --- a/arch/x86/xen/mmu.c >> +++ b/arch/x86/xen/mmu.c >> @@ -116,6 +116,7 @@ static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss; >> DEFINE_PER_CPU(unsigned long, xen_cr3); /* cr3 stored as physaddr */ >> DEFINE_PER_CPU(unsigned long, xen_current_cr3); /* actual vcpu cr3 */ >> >> +static phys_addr_t xen_pt_base, xen_pt_size; > > These be __init, but the use of globals in this way is confusing. How else would you want to do it? > >> >> /* >> * Just beyond the highest usermode address. STACK_TOP_MAX has a >> @@ -1998,7 +1999,9 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) >> check_pt_base(&pt_base, &pt_end, addr[i]); >> >> /* Our (by three pages) smaller Xen pagetable that we are using */ >> - memblock_reserve(PFN_PHYS(pt_base), (pt_end - pt_base) * PAGE_SIZE); >> + xen_pt_base = PFN_PHYS(pt_base); >> + xen_pt_size = (pt_end - pt_base) * PAGE_SIZE; >> + memblock_reserve(xen_pt_base, xen_pt_size); > > Why not provide a xen_memblock_check_and_reserve() call that has the > xen_is_e820_reserved() check and the memblock_reserve() call? This may > also be useful for patch #9 as well. Uuh, not really. memblock_reserve() for those areas is called much earlier than the e820 map is constructed. Thinking more about it, I even have to modify patch 11 and 13: relocation must be done _after_ doing the memblock_reserve() of all pre-populated areas to avoid relocating to such an area. Juergen