lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 9 Apr 2008 10:54:40 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Matti Aarnio <matti.aarnio@...iler.org>
Cc:	Zhao Forrest <forrest.zhao@...il.com>,
	Andi Kleen <andi@...stfloor.org>, discuss@...-64.org,
	linux-kernel@...r.kernel.org, yhlu.kernel@...il.com, ak@...e.de
Subject: Re: Does Linux have plan to support memory hole remapping?


* Matti Aarnio <matti.aarnio@...iler.org> wrote:

> On Wed, Apr 09, 2008 at 10:01:59AM +0200, Andi Kleen wrote:
> > "Zhao Forrest" <forrest.zhao@...il.com> writes:
> > >
> > > As we can see from above information that the physical memory in system
> > > is 32768MB(32GB). However OS is only using about
> > > (32768-512)MB(MemTotal:     33010240 kB). Does this mean that this
> > > linux kernel can't use the physical memory remapped
> > > from (4G-512M, 4G) to (32G, 32G+512M)?
> > 
> > The linux kernel can only use the memory passed to it by the BIOS.
> > Sometimes they need special BIOS setup options to enable remapping. If
> > there are no such options and you can't upgrade it you're out of luck
> > 
> > I would suggest you contact your system vendor.
> 
> I second that.  On my home machine I have early ASUS AMD x64 board 
> from a few years ago.  For it I did buy CPU with this memory mapping 
> hardware inside, but the BIOS did not support it correctly until a 
> year or two latter, thus I was not able to use all of 4 GB of memory I 
> had installed there. There was support in BIOS from start, but it did 
> things wrong.

having said that - but we'll still consider sane looking patches that 
allow the remapping of otherwise inactive RAM. [ We might not even have 
to touch the system chipset beyond what Linux already knows about it: in 
theory someone might want to try a hack to GART remap such RAM areas and 
use a sparse mem map entry to map it to Linux - if the identity of that 
RAM is crystal-clear and there's enough GART space available. But even 
then it's probably still at best a dangerous and fragile hack. ]

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ