linux-kernel - Re: [RFC PATCH 1/2] pci: don't assume pref memio are 64bit -v3

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:	Thu, 23 Apr 2009 16:36:19 +0400
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	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: [RFC PATCH 1/2] pci: don't assume pref memio are 64bit -v3

On Wed, Apr 22, 2009 at 03:37:04PM -0700, Yinghai Lu wrote:
> one system with 4g installed ( there is 1g hole)
> 
> when 4G installed.
> BIOS put ACPI etc need the hole
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
> [    0.000000]  BIOS-e820: 000000000009bc00 - 00000000000a0000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000e3000 - 0000000000100000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bffa0000 (usable)
> [    0.000000]  BIOS-e820: 00000000bffa0000 - 00000000bffae000 (ACPI data)
> [    0.000000]  BIOS-e820: 00000000bffae000 - 00000000bfff0000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000bfff0000 - 00000000c0000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
> [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
> so in kernel resource will be reserved for 0xbffa0000 - 0xbfff0000 for ACPI
> 0x100000 -  0xbffa0000 for RAM...
> 
> and BIOS set
> [    0.240007] pci 0000:00:01.0: bridge 64bit mmio pref: [0xbdf00000-0xddefffff]
> [    0.237102] pci 0000:01:00.0: reg 10 32bit mmio: [0xc0000000-0xcfffffff]
> that is conflict with reserved res. so it can not be reserved Kernel.
> 
> then Kernel try to get range from 0x140000000 ( above the RAM, 5G and above 4g)
> and set let the bridge to use it, and ATI cards to use it.
> 
> but the problem is that ATI only support 32bit ...

Yinghai, you are trying to get a quick fix for quite a complex problem
that cannot be solved with a quick fix. Even more, there is no rush on
a quick fix because it's not a critical bug at all. 32-bit stuff ends
up above 4G *only* when there is no free space left on the 32-bit
PCI bus, and it can be considered as very effective (though rather ugly)
way of disabling the BAR that we failed to allocate.
In this particular case it was simply a side effect of the "pci_mem_start"
issue (which was indeed critical, but hopefully fixed now).


> +/* need to insert those two under iomem */
> +struct resource iomem32_resource = {
> +	.name	= "PCI mem 32bit",
> +	.start	= 0,
> +	.end	= 0xffffffff,
> +	.flags	= IORESOURCE_MEM,
> +};
> +struct resource iomem64_resource = {
> +	.name	= "PCI mem 64bit",
> +	.start	= 1ULL<<32,
> +	.end	= -1,
> +	.flags	= IORESOURCE_MEM | IORESOURCE_MEM_64,
> +};
> +

This only works on x86 and similar systems with 1:1 CPU address to bus
address mapping. There is a lot of machines with multiple 32-bit PCI
bus spaces (4G per PCI domain).

Ivan.
--
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/