From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756423AbbICPBq (ORCPT ); Thu, 3 Sep 2015 11:01:46 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:26135 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754124AbbICPBp (ORCPT ); Thu, 3 Sep 2015 11:01:45 -0400 X-IronPort-AV: E=Sophos;i="5.17,462,1437436800"; d="scan'208";a="300799311" Message-ID: <55E860D5.5050609@citrix.com> Date: Thu, 3 Sep 2015 16:01:41 +0100 From: David Vrabel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Juergen Gross , =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , CC: , Boris Ostrovsky Subject: Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting References: <1441281916-38284-1-git-send-email-roger.pau@citrix.com> <55E83C46.8010701@suse.com> <55E85B61.4070203@citrix.com> <55E85CF3.40705@citrix.com> <55E85EB6.7060307@citrix.com> <55E85F52.9030708@suse.com> In-Reply-To: <55E85F52.9030708@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/09/15 15:55, Juergen Gross wrote: > On 09/03/2015 04:52 PM, David Vrabel wrote: >> On 03/09/15 15:45, David Vrabel wrote: >>> On 03/09/15 15:38, Roger Pau Monné wrote: >>>> El 03/09/15 a les 14.25, Juergen Gross ha escrit: >>>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote: >>>>>> On systems with memory maps with ranges that don't end at page >>>>>> boundaries, >>>>>> like: >>>>>> >>>>>> [...] >>>>>> (XEN) 0000000000100000 - 00000000dfdf9c00 (usable) >>>>>> (XEN) 00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS) >>>>>> [...] >>>>>> >>>>>> xen_add_extra_mem will create a protected range that ends up at >>>>>> 0xdfdf9c00, >>>>>> but the function used to check if a memory address is inside of a >>>>>> protected >>>>>> range works with pfns, which means that an attempt to map 0xdfdf9c00 >>>>>> will be >>>>>> refused because the check is performed against 0xdfdf9000 instead of >>>>>> 0xdfdf9c00. >>>>>> >>>>>> In order to fix this, make sure that the ranges that are added to the >>>>>> xen_extra_mem array are aligned to page boundaries. >>>>>> >>>>>> Signed-off-by: Roger Pau Monné >>>>>> Cc: Konrad Rzeszutek Wilk >>>>>> Cc: Boris Ostrovsky >>>>>> Cc: David Vrabel >>>>>> Cc: Juergen Gross >>>>>> Cc: xen-devel@lists.xenproject.org >>>>>> --- >>>>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2. >>>>>> --- >>>>>> arch/x86/xen/setup.c | 6 ++++++ >>>>>> 1 file changed, 6 insertions(+) >>>>>> >>>>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c >>>>>> index 55f388e..dcf5865 100644 >>>>>> --- a/arch/x86/xen/setup.c >>>>>> +++ b/arch/x86/xen/setup.c >>>>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t >>>>>> start, phys_addr_t size) >>>>>> { >>>>>> int i; >>>>>> >>>>>> + start = PAGE_ALIGN(start); >>>>>> + size &= PAGE_MASK; >>>>> >>>>> This is not correct. If start wasn't page aligned and size was, you'll >>>>> add one additional page to xen_extra_mem. >>>> >>>> I'm not understanding this, let's put an example: >>>> >>>> start = 0x8c00 >>>> size = 0x1000 >>>> >>>> After the fixup added above this would become: >>>> >>>> start = 0x9000 >>>> size = 0x1000 >>>> >>>> So if anything, I'm adding one page less (because 0x8000 was partly >>>> added, and with the fixup it is not added). >>> >>> We expand the reserved (i.e., non-RAM) areas down so they're fully >>> covered with whole pages when we depopulate and 1:1 map them, we should >>> add extra memory regions that cover these same areas. >> >> Ignore this. This was nonsense. >> >> We expand the reserved (i.e., non-RAM) areas so they're fully covered >> with whole pages when we depopulate and 1:1 map them, we should add the >> extra memory such that it does not overlap with with expanded regions. >> i.e., round up the start and round down the end (like Roger's patch >> does). > > Nearly. Roger's patch rounds up start and rounds down the size. It might > add non-RAM partial pages to xen_extra_mem. Yes. You're right. David