linux-kernel - Re: [PATCH] x86/pci: intel bus root res with IOH reading -v2

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: <4ACB839A.2060800@kernel.org>
Date:	Tue, 06 Oct 2009 10:51:22 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86/pci: intel bus root res with IOH reading -v2

Bjorn Helgaas wrote:
> On Sunday 04 October 2009 10:54:24 pm Yinghai Lu wrote:
>> for intel system with multi IOH. we could read peer root resource from PCI conf,
>> and don't trust _CRS again for root bus
> 
> Ugh.  Are we going to end up with amd_bus.c, intel_bus.c, nvidia_bus.c,
> broadcom_bus.c, serverworks_bus.c, etc.?
only needed when you have muti ...
> 
> This is basically a simple PCI host bridge driver, but it's completely
> separate from the ACPI pci_root.c driver, and it completely ignores
> useful things like multiple domain (_SEG) support and address translation
> (_TRA) support.  These are going to be important issues for large x86
> machines.
> 
> I think this is leading toward an architectural mess.  Yes, we have
> issues with _CRS for root bridges.  But ACPI does give us a generic
> framework powerful enough to handle everything you're doing here.  In
> my opinion, we should fix the implementation issues with that framework
> rather than adding platform-specific setup code every time we trip
> over something.

again we should trust HW conf than BIOS.

> 
> I expect that will mean some quirks in pci_root.c, and maybe even some
> code similar to pci_root_bus_res() to validate or override what we learn
> from _CRS.  But we ought to try for some conceptual integrity in the
> design by putting all the putting all the host bridge driver code together.
> 
> What is the specific problem solved by this patch?  Does "pci=use_crs"
> address any of that problem?  (I know "pci=use_crs" breaks some machines,
> and I know it's unacceptable to require users to use it.  But I want to
> understand whether the concept is related, and whether you've tripped
> over a BIOS defect or a Linux pci_root.c defect.)

BIOS doesn't allocate resource to some pci devices when too many devices. and need kernel to allocate resource ( 32bit mmio, 64 mmio)
to those devices.
current only known fw that can allocate mmio 64 ( with correct setting) is LinuxBIOS.

also could help os to fend off some range that is wrongly allocated by BIOS that is cross the boundary between different peer root bus.

_CRS doesn't report any MMIO 64 range, even HW does have that set. 

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