Support 2GB of memory on Malta systems with FreeBSD/mips.

[jhb]

Summary

When 2GB of memory is enabled for QEMU's Malta emulation, the physical
memory ends at an address of 2^32 - 1. This causes an integer overflow
to zero when computing the upper bound of the second phys_avail[] range.
As a result, FreeBSD/mips kernels were only using the first 256MB of
RAM and ignoring the remaining 1.75GB. To work around this, truncate
the extended memory size to 2GB minus one page for 32-bit mips kernels.

Review request is more if there is a cleaner way to detect/handle the
overflow. The rather complicated mapping of physical address to RAM
in Malta is perhaps best explained here:

https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg04382.html

Test Plan

• boot FreeBSD/mips under qemu-system-mips with -m 2048.

[kib]

Where the overflow occurs ? In this line ?

		phys_avail[3] = 0x90000000 + (ememsize - memsize);

phys_avail[x + 1] convention is to point to the byte next after the last byte of the region. For i386 this seems to be not a problem in real life due to the conveniently located PCI hole.

I do not see anything wrong with explicitly capping the amount of supported memory. Perhaps it can be done more elegantly by adding to 2G+256M and checking for overflow, but the end result is same, so I am not sure it its important.

[jhb]

In D16027#339568, @kib wrote:

Where the overflow occurs ? In this line ?

		phys_avail[3] = 0x90000000 + (ememsize - memsize);

Yes.

phys_avail[x + 1] convention is to point to the byte next after the last byte of the region. For i386 this seems to be not a problem in real life due to the conveniently located PCI hole.

Right.

I do not see anything wrong with explicitly capping the amount of supported memory. Perhaps it can be done more elegantly by adding to 2G+256M and checking for overflow, but the end result is same, so I am not sure it its important.

Yeah, I looked at detecting the overflow closer to the line in question, but it seemed a bit messier code-wise (though I was trying to do it based on the math in question rather than just the value of ememsize. I could just move the current code perhaps). Also, in theory changing ememsize is more consistent as it affects 'realmem' and anything that uses that.