linux-kernel - Re: [RFC] use realmode code to reserve end-of-conventional-memory to 1MB

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]

Message-ID: <47CECC8D.9090507@goop.org>
Date:	Wed, 05 Mar 2008 08:38:37 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Eduardo Habkost <ehabkost@...hat.com>
CC:	Ian Campbell <ijc@...lion.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>,
	Alexander van Heukelum <heukelum@...lshack.com>,
	Ingo Molnar <mingo@...e.hu>,
	Alexander van Heukelum <heukelum@...tmail.fm>,
	Andi Kleen <ak@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
	Mark McLoughlin <markmc@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] use realmode code to reserve end-of-conventional-memory
 to 1MB

Eduardo Habkost wrote:
> On Thu, Feb 28, 2008 at 11:16:49PM +0000, Ian Campbell wrote:
>   
>> The patch below seems like the right thing to do. It certainly boots in
>> a domU without the DMI problem (without any of the other related patches
>> such as Alexander's).
>>
>> However ddcprobe hangs when run -- need to investigate some more, vm86
>> in general works ok (i.e. my vm86 test code passes).
>>
>> BTW Jeremy, the kernel doesn't use XENMEM_memory_map -- any reason other
>> than it not being useful at the time? These days the tools can push an
>> arbitrary e820 down for a guest which might be useful to support,
>> although nothing interesting is done with it today.
>>
>> Ian.
>>
>> x86/xen: Construct e820 map with a hole between 640K-1M.
>>
>> Signed-off-by: Ian Campbell <ijc@...lion.org.uk>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: Ingo Molnar <mingo@...hat.com>
>> Cc: H. Peter Anvin <hpa@...or.com>
>> Cc: Jeremy Fitzhardinge <jeremy@...p.org>
>> ---
>>  arch/x86/xen/setup.c |    3 ++-
>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 3bad477..2341492 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -38,7 +38,8 @@ char * __init xen_memory_setup(void)
>>  	unsigned long max_pfn = xen_start_info->nr_pages;
>>  
>>  	e820.nr_map = 0;
>> -	add_memory_region(0, PFN_PHYS(max_pfn), E820_RAM);
>> +	add_memory_region(0, LOWMEMSIZE(), E820_RAM);
>> +	add_memory_region(HIGH_MEMORY, PFN_PHYS(max_pfn)-HIGH_MEMORY, E820_RAM);
>>     
>
> Won't this waste 300+ KB of Perfectly Good RAM? Or I understood it
> incorrectly?
>
> I am aware that it would take more work to tell all kernel code that it
> shouldn't look for BIOS data on this region when running as a domU guest,
> but it seems that it would be a better solution.

For the moment that's true, but we should be able to release those 
pages.  On the other hand, there's been talk of making Xen hand out 
memory in physically contigious 2M chunks, which means trying to unmap 
300k won't be possible or worthwhile.  I suspect real hardware will just 
waste this memory too (it won't remap that 320k of ram to somewhere 
else; it will just be shadowed) - which is nothing compared to chipsets 
which will just throw away 1G to make space for PCI...

    J
--
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/