[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |