[PATCH] Fix hw.physmem use with ACPI..

[John Baldwin]

Several folks had problems using hw.physmem with ACPI as depending on
where the system's ACPI tables were located in physical address space,
using the hw.physmem tunable could result in the kernel zero'ing part
of the ACPI tables.  This resulted from the rather peculiar behavior of
the hw.physmem/MAXMEM tunable.

A (relatively) long time ago in FreeBSD land, machines did not provide
a reliable way of detecting how much memory was installed (and/or
FreeBSD didn't reliable detect it).  As a result, the MAXMEM/hw.physmem
stuff was added with 2 apparent purposes.  First off, any memory above
that limit was not to be used, so it could cap memory usage.  The
second purpose is more curious though.  If the system had claimed to
have less than MAXMEM, the kernel would extend the last memory segment
up to MAXMEM.  Thus, if your system had 64 MB of RAM but only detected
16, you could use MAXMEM to force it to see all 64 MB.

This second feature is what got machines into trouble.  Modern machines
(such as those with ACPI) all include a BIOS-supplied map of physical
memory (known as the SMAP (I think it stands for system map)) that
specifies which regions of the physical address space are available
RAM, which are reserved for the BIOS or devices, etc.  On these
systems, we can trust the SMAP, and extending the top of memory can
only produce pain (e.g. moving the top of memory up into the area
reserved for ACPI tables).

All this is to provide the background for the change in this patch.
The patch is simple.  If we used the SMAP to figure out our memory map,
then we turn off the second feature of MAXMEM and just use it to cap
the top of memory.  Since amd64 always uses the SMAP, the second
feature has been axed altogether on that platform.

http://www.FreeBSD.org/~jhb/patches/hw.physmem.patch

Please test it.  Especially if you used to have problems using
hw.physmem with ACPI in the past.

-- 
John Baldwin