From mboxrd@z Thu Jan 1 00:00:00 1970 From: Malcolm Crossley Subject: Re: [PATCH] [RFC] xen: Fix memory hotplug end limit test for updating compat M2P table Date: Tue, 24 Apr 2012 17:02:02 +0100 Message-ID: <4F96CE7A.2030906@citrix.com> References: <8470671d407f4f74b499.1335204443@malcolmc-Precision-WorkStation-T3500> <4F967099020000780007F81F@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F967099020000780007F81F@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: "Tim (Xen.org)" , xen-devel List-Id: xen-devel@lists.xenproject.org On 24/04/12 08:21, Jan Beulich wrote: >>>> On 23.04.12 at 20:07, Malcolm Crossley wrote: >> The memory hotplug code was masking the hotplugged memory start address and >> comparing to a shifted version of COMPAT MPT size but not doing the same for >> the end address. >> This patch applies the same shifting and masking to the end address and >> reapplies the mask if the end address has been clamped. > This lacks a Signed-off-by tag in any case. > > I'm not, however, seeing what is being fixed here: > RDWR_COMPAT_MPT_VIRT_{START,END} are both aligned to a > 1Gb boundary, so I'm not immediately seeing how the adjustment > would result in any changed behavior. > > Also, assuming I'm overlooking something and the patch is indeed > needed (and hence you'll resubmit), please fix the indentation to > not use hard tabs, and adjust the lines you change anyway to > match Xen's coding style. > > Jan I didn't include a signed off by because it's an RFC patch and I wasn't completely sure the change was required. I kept the code style of the existing code around the patch but I will update it to Xen coding style in the future and it was my mistake for using hard tabs and my editor has been reconfigured so it won't happen in the future. The key fix is the patch is that epfn is being compared to (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) without a 2 bit shift. This means that epfn is being compared to the size of the RDWR_COMPAT_MPT table instead of the maximum number of entries the RDWR_COMPAT_MPT table can contain. This could result in the end regions of hotplugged memory being inaccessible when using the RDWR_COMPAT_MPT table. I also moved the epfn masking to occur before the comparison to RDWR_COMPAT_MPT to be consistent with the spfn comparison code. I can split the patch for to make the changes clearer if you want? Malcolm >> diff -r 274e5accd62d -r 8470671d407f xen/arch/x86/x86_64/mm.c >> --- a/xen/arch/x86/x86_64/mm.c >> +++ b/xen/arch/x86/x86_64/mm.c >> @@ -446,6 +446,8 @@ static int setup_compat_m2p_table(struct >> int err = 0; >> >> smap = info->spfn& (~((1UL<< (L2_PAGETABLE_SHIFT - 2)) -1)); >> + emap = ( (epfn + ((1UL<< (L2_PAGETABLE_SHIFT - 2)) - 1 ))& >> + ~((1UL<< (L2_PAGETABLE_SHIFT - 2)) - 1) ); >> >> /* >> * Notice: For hot-added memory, only range below m2p_compat_vstart >> @@ -454,11 +456,11 @@ static int setup_compat_m2p_table(struct >> if ((smap> ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>> >> 2)) ) >> return 0; >> >> - if (epfn> (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)) >> - epfn = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>> 2; >> - >> - emap = ( (epfn + ((1UL<< (L2_PAGETABLE_SHIFT - 2)) - 1 ))& >> - ~((1UL<< (L2_PAGETABLE_SHIFT - 2)) - 1) ); >> + if (emap> ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>> 2)) >> + { >> + emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START)>> 2; >> + emap = emap& ~((1UL<< (L2_PAGETABLE_SHIFT - 2)) - 1); >> + } >> >> va = HIRO_COMPAT_MPT_VIRT_START + >> smap * sizeof(*compat_machine_to_phys_mapping); >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > >