Hello Andrew,
On 25.07.17 19:23, Andrew Cooper wrote:
As a general rule, Xen needs to be able to tolerate and cope with any
quantity of crap described by the firmware. On the x86 side, we have
large quantities of workarounds for buggy ACPI/MP/SMBIOS tables.
That approach somehow covered with early mentioned options:
On 25.07.17 15:24, Andrii Anisov wrote:
* ignore next duplicating (overlapping) memory node in favor of one
already in a memory banks list
* merge duplicating (overlapping), even neighboring, memory banks
On 25.07.17 19:23, Andrew Cooper wrote:
It might be the case that the best Xen can do is give up, but it should
do so with a clear error message identifying what the firmware has done
which is sufficiently crazy to prevent further booting.
We have one more option to choose for the case:
* BUG() with clear notification at the moment we are trying to add
overlapping memory bank
So what to choose?
ps:
Hitting a BUG()
Actually silently dying without earlyprintk enabled in this case. It
happens pretty early.
--
*Andrii Anisov*
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
