On Tue, Jul 22, 2014 at 2:00 AM, Ian Campbell Ian.Campbell@citrix.com wrote:
On Mon, 2014-07-21 at 20:54 -0700, Roy Franz wrote:
On Mon, Jul 21, 2014 at 8:47 PM, Fu Wei fu.wei@linaro.org wrote:
I agree with you for the multiple banks of memory. Will try to use the first bank, and report the result here. :-)
Yes, I had to limit allocations to the low bank on the FVP model in the stub. My first patch series avoided this problem by marking the memory used to load modules as a mem-reserve region in the memory map so XEN would not try to use that memory (when it freed the modules it would check against reserved regions before trying to re-use the memory.) The upper banks can be accessed, but not mapped by XEN.
I don't have a generic solution for this yet.
Irrespective of Xen's (lack of) support for multiple memory banks we (by which I mean I) should make it handle the case where the initial modules are not in regions which it considers to be RAM and/or reserved regions which are not RAM.
Based on the description it seems that the problem is probably in discard_initial_modules() which will free the modules without checking if they are within RAM so it runs off the end of the frametable array, does that sound right?
If you comment out the call to dt_unreserved_regions in that function does it work OK? If so then I'll figure out a proper solution.
Yes, it is the discard_initial_modules() that is the problem - if that tries to free and use memory from modules that is in the high bank it goes boom. My initial DT hack accidentally avoided this by making the modules reserved regions which made this operation a NOP.
If we add proper handling of modules outside of the frametable this takes care of most of the ugliness. The remaining issue is that the EFI memory map is generally much more sparse that the DT memory banks, so the logic used to avoid over-sparseness will need to be updated. A pathological EFI memory map could be very sparse at the beginning and cause too little memory to be used.
Roy
Ian.