WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: question on c/s 15964

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 27.09.07 09:51 >>>
>On 27/9/07 08:02, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> in the new function reserve_e820_ram() you do nothing *and* return 0 
>> (success)
>> if an entry would need to be split but there's no room. This seems dangerous
>> to
>> me; in the original version of the patch I had sent I truncated the entry
>> instead,
>> choosing the variant (start or end) that resulted in less loss of memory.
>
>Yes, that's probably a better option. Or lose entries from the end of the
>e820map (which is what silently happens if the BIOS offers more than 128
>entries in the first place). Or perhaps just BUG_ON()?

BUG_ON() for more than 128 entries coming from the BIOS seems reasonable
to me; BUG_ON() because of internal needs to split entries doesn't seem right
(as you use the function for other than dealing with the DMI table problem).
Losing entries seems a reasonable alternative to cutting of ones, but this
would then need to be done for E820_RAM entries only, and should perhaps
attempt to find the smallest one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>