"Anywhere in RAM"--to include where we load the kernel by default? If this
is the case, not only does the bootloader need to scan and avoid, but
setup.S needs to be made relocatable--to include the "empty" zero page.
After settling these issues, it should be relatively easy for the memory
initialization code to avoid these tables. Give us a hook, and we can
reserve them.
Linus, I'm not certain that a bios would return the area reserved, as
reserved regions are designated eternally. If these tables can be
overwritten once read, they would be AddressRangeACPI - like. Unless these
tables ARE to be held reserved forever, which would explain why there is no
AddressRangeSMPTable type in the ACPI standard.
Nathan
http://www.teleport.com/~acpi/DOWNLOADS/ACPIspec10b.pdf
> -----Original Message-----
> From: Lyle Coder [mailto:x_coder@hotmail.com]
>
> Linus,
> The actual MP table which is pointed to by the floating point
> structure CAN
> actually be anywhere in the RAM. Only the floating pointer
> is in the places
> you mentioned. The correct approach may be to scan the
> tables in the boot
> loader.
>
> On Fri, 25 Feb 2000, Ingo Molnar wrote:
> >
> >i'd love to do this as well, but there is one big problem:
> the SMP-config
> >parsing code has to run ASAP, before any memory is
> destroyed. It can be
> >anywhere in the BIOS sections of the lower 1MB RAM. So allocating and
> >initializing page tables will cause problems. We could allocate page
> >tables from above 1MB, but this is just yet another implicit 'reserve
> >memory' thing we tried to get rid of via bootmem :-)
>
> Sure. It needs to get solved, though, and for future systems we will
> simply have to initialize the page tables first: I already have intel
> engineers knocking on my door telling me that the systems they have in
> their labs can't do SMP because of this. Let's assume that
> they are on the
> market in another few months..
>
> Note that the SMP tables really should _not_ be in just any low memory
> area: if that were true then we'd have trashed them much
> earlier during
> the bootloader anyway. Currently the SMP tables should be
> either in the
> extended BIOS area (really low memory) or in the 640kB-1M
> region (or just
> below, in the "high BIOS area", which we should have full knowledge of
> from the e820 BIOS memory information)...
>
> In fact, right now we don't even search for it in any other areas than
>
> low 1kB (extended low BIOS area)
> 1kB just under 640kB (extended high BIOS area)
> last 64kB of the first 1MB area (BIOS section)
>
> and sure, the physical hardware table can be anywhere (and this is the
> part that _will_ be in high high memory on newer boards), but
> it should
> still all be in reserved BIOS memory that we wouldn't touch anyway.
>
> So I think that the problem you refer to is the old problem
> of Linux not
> having the complete memory map, so Linux would always assume
> that memory
> up to the 640kB mark was usable. That is definitely not true,
> but that bug
> got fixed with the introduction of the e820 memory table parsing..
>
> >yep, i agree. I gave it a quick shot and we crash in
> smpboot.c line 864,
> >which crash can be explained because smp_boot_cpu_id is
> taken from the MP
> >config table.
>
> Not surprising. We probably have tons of small ordering
> assumptions that
> just never came up..
>
> Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:13 EST