Then in LinuxBIOS We can access the memory in 64 bit mode directly. And maybe do the memory check and test. Memory problem is a big problem in system integration.
Some time 8 ways system, every cpu has 4 dimm, total memay will be 4G*4*8=128G.
Regards
YH
-----邮件原件----- 发件人: ebiederman@lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年6月1日 10:41 收件人: YhLu 抄送: Stefan Reinauer; LinuxBIOS 主题: Re: Large mmio resources and 4G+ of RAM...
YhLu YhLu@tyan.com writes:
Eric,
There is something called Memory lifting or memory remapping for Opteron. For example if 2G for one Opteron and two ways system.
Then the CPU 0 will use [0,2G), and CPU 1 will use [4G, 6G).
If the RAM for CPU is above 4G, then We must lost 1/2G for MMIO range, the reason is Opteron only has two reg for RAM LOW and HIGH limit. And there
is
no other regs to record the memory hole. But it seems Intel CPU has more regs to remember the memory hole.
Memory lifting is nice. And in certain specific instances it is useful. On the Opteron it is possible to move either Memory controllers, or DIMMS. At 4G per memory controller it does not work to move memory controllers, at paired singled sided 2G DIMMS you can't move DIMMS.
So the other solution is to move the large MMIO resources. Moving the MMIO resources has the advantage that A) It is simple. B) It works in all circumstances (baring issues with bridges) C) Is needed if you have many large MMIO regions. D) It works on all CPUs. E) A 32bit kernel could support it with highmem type tricks...
So I think I would rather pursue moving the large MMIO resources first. The limited utility of memory lifting doesn't inspire me to worry about it.
Although the few circumstances the Opteron memory lifting applies to may be the only cases people really care about loosing that much memory.
Eric