On Mon, 2014-07-21 at 17:43 -0700, Roy Franz wrote:
I think this patchset is in good shape, with the exception of the usage of the EFI memory map, which I am looking for some suggestions on. The current implementation populates the bootinfo memory bank list from the EFI memory map, rather than from the device tree, and doesn't use any reserved ranges. This works, however the EFI memory map can contain a lot of entries, many of which are small. Depending on the layout, this could trigger the code that sets up the frametable to discard most of memory. Also, as a side effect of some memory being ignored to manage the frametable size, the EFI stub needs to ensure that it loads modules into memory that XEN is going to map. The FVP model has 2GBytes of DRAM at 0x80000000 and another 2 at 0x800000000, so the disjoint case is common.
It seems that both these problems go largely away if sparse frametable mappings are supported, but I'm not sure how much effort that would be. I think most of the work done to handle things robustly with the non-sparse frametable would not apply once a sparse frametable is supported. Does adding support for a sparse frametable mapping seem like a reasonable way forward on this?
I think so, we need this for many reasons other than the issues it causes with EFI anyway.
Ian.