[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: fix determination of bit count for struct domain allocations



>>> On 14.03.14 at 16:51, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 14/03/14 15:46, Jan Beulich wrote:
>>>>> On 14.03.14 at 16:30, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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 <jbeulich@xxxxxxxx>
>>>>
>>>> --- 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.