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

[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


 


Rackspace

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