linux-kernel - Re: [PATCH] x86/pci: make pci_mem

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: <49E8FD0B.2050308@zytor.com>
Date:	Fri, 17 Apr 2009 15:04:59 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org, yannick.roehlly@...e.fr
Subject: Re: [PATCH] x86/pci: make pci_mem_start to be aligned only -v4

Ingo Molnar wrote:
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
>> On Fri, 17 Apr 2009, Ingo Molnar wrote:
>>> Could we perhaps round up to 1MB in this case too?
>> (The below 1MB one).
>>
>> I'd argue against it, at least in this incarnation. I can well 
>> imagine somebody wanting to do resource management in the 640k-1M 
>> window, so..
> 
> ok - indeed - if there's some super-small system with limited 
> address lines and all physical addresses tightly packed with RAM?
> 

No, much more likely that you're having PCI 2.x or PnP devices which 
have 20-bit resources.  It's probably worth noting that at least right 
now, Linux mishandles 20-bit BARs and treat them like 32-bit BARs.  It 
turns out to actually work on a majority of the (quite few) known 
devices which do have 20-bit BARs.

> 
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)       0.639 MB RAM
>  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)     0.001 MB
>                                                 [ hole ]       0.250 MB
>  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)     0.125 MB
>  BIOS-e820: 0000000000100000 - 000000003ed94000 (usable)    1004.5   MB RAM
>  BIOS-e820: 000000003ed94000 - 000000003ee4e000 (ACPI NVS)     0.7   MB
>  BIOS-e820: 000000003ee4e000 - 000000003fea2000 (usable)      16.3   MB RAM
>  BIOS-e820: 000000003fea2000 - 000000003fee9000 (ACPI NVS)     0.3   MB
>  BIOS-e820: 000000003fee9000 - 000000003feed000 (usable)       0.15  MB RAM
>  BIOS-e820: 000000003feed000 - 000000003feff000 (ACPI data     0.07  MB
>  BIOS-e820: 000000003feff000 - 000000003ff00000 (usable)       0.004 MB RAM
>                                                 [ hole ]       1.0   MB
>                                                 [ hole ]    3072.0   MB
> 
> On this map, using your scheme, we'd fill up that small 1MB hole up 
> to 1GB [mockup]:
> 
>  BIOS-e820: 000000003ff00000 - 0000000040000000 (RAM buffer)
> 
> I guess that's a good thing not just for robustness: a chipset might 
> be faster when DMA or mmio is on some well-isolated physical memory 
> range, not too close to real RAM or other devices?
> 

Realistically, there probably is RAM there, probably consumed by the SMM 
T-seg.

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