From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86: fix determination of bit count for struct domain allocations Date: Fri, 14 Mar 2014 16:18:56 +0000 Message-ID: <53232BF0.5040006@citrix.com> References: <53232CEF020000780012443B@nat28.tlf.novell.com> <53232083.6080502@citrix.com> <532332790200007800124467@nat28.tlf.novell.com> <53232578.80403@citrix.com> <5323389A02000078001244B8@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WOUpA-0001cB-Iy for xen-devel@lists.xenproject.org; Fri, 14 Mar 2014 16:19:08 +0000 In-Reply-To: <5323389A02000078001244B8@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: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 14/03/14 16:12, Jan Beulich wrote: >>>> On 14.03.14 at 16:51, Andrew Cooper wrote: >> On 14/03/14 15:46, Jan Beulich wrote: >>>>>> On 14.03.14 at 16:30, Andrew Cooper wrote: >>>> On 14/03/14 15:23, Jan Beulich wrote: >>>>> We can't just add in the hole shift value, as the hole may be at or >>>>> above the 44-bit boundary. Instead we need to determine the total bit >>>>> count until reaching 32 significant (not squashed out) bits in PFN >>>>> representations. >>>>> >>>>> Signed-off-by: Jan Beulich >>>>> >>>>> --- a/xen/arch/x86/domain.c >>>>> +++ b/xen/arch/x86/domain.c >>>>> @@ -180,6 +180,19 @@ void dump_pageframe_info(struct domain * >>>>> spin_unlock(&d->page_alloc_lock); >>>>> } >>>>> >>>>> +static unsigned int __init noinline _domain_struct_bits(void) >>>> noinline for debugging purposes? >>> No, for it to really end up in .init.text (as the caller is in .text). >> In which case it should assert/bug if the function returns 0, to be sure >> we will never fall into the unlikely case again and try to call it from >> a non-init function. Also a comment to explain this. > I really dislike asserting the absolutely obvious: The function can > be very easily proven to only return values in the range [44,64]. > > Jan > Hmm ok, but at the very least this deserves a comment to that effect. ~Andrew