[Xen-devel] Re: [GIT PULL] Small Xen bugfixes

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

 On 10/31/2010 02:13 AM, Ian Campbell wrote:
>> The 3rd is certainly simplest, at the cost of wasting a trivial amount
>> of memory.
> Doesn't Linux avoid using the lowest 1M anyway? (obviously apart from
> the start of day probing for firmware tables etc).

No, it tries to use most of it I think.  It will tend to avoid the low
64k (maybe more) to avoid BIOS bugs.

>>   Unfortunately it crashes early.  Sigh, will try and sort it
>> out this afternoon.
> Strange!

I didn't get a chance to poke at it again, but in retrospect, I think
there are various "must succeed" allocations in low memory.  We don't
need those allocations (things like AP boot trampoline, etc), but we
don't bother to stub them out or prevent them from happening.  Reducing
the system to one with *no* allocatable memory below 1M is just too
strange, and would be a continuous source of problems in the future.

Of the other two options, I think your original approach is going to be
simplest.  E820 gap filling wouldn't be too bad, but we'd end up having
to add a bit of gap-tracking logic to the E820 loop which isn't
currently there.  Ignoring sub-1M gaps is simpler (and it needn't be
conditional on xen_initial_domain(), because we would never expect to
see anything strange sub-1M in a domU, and if there is, we should still
be careful of it in case something odd is going on).

    J

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