於 三，2012-07-04 於 10:56 +0800，lee joey 提到： > > > ---------- Forwarded message ---------- > From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > Date: 2012/6/7 > Subject: Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at > first > To: Steven Newbury <steve@xxxxxxxxxxxxxxx> > Cc: Yinghai Lu <yinghai@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, > David Miller <davem@xxxxxxxxxxxxx>, Tony Luck <tony.luck@xxxxxxxxx>, > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Andrew Morton > <akpm@xxxxxxxxxxxxxxxxxxxx>, linux-pci@xxxxxxxxxxxxxxx, > linux-kernel@xxxxxxxxxxxxxxx > > > On Wed, Jun 6, 2012 at 2:44 AM, Steven Newbury <steve@xxxxxxxxxxxxxxx> > wrote: > > On Tue, 5 Jun 2012, 06:04:57 BST, Yinghai Lu <yinghai@xxxxxxxxxx> > wrote: > >> > Linux has a long history of allocating bottom-up. Windows has a > long > >> > history of allocating top-down. You're proposing a third > alternative, > >> > allocating bottom-up starting at 4GB for 64-bit BARs. If we > change > >> > this area, I would prefer something that follows Windows because > I > >> > think it will be closer to what's been tested by Windows. Do you > >> > think your alternative is better? > >> > >> hope we can figure out how windows is making it work. > >> > >> Steve, Can you check if Windows is working with your test case ? > >> > >> If it works, we may try do the same thing from Linux, so you will > not > >> need to append "pci=nocrs pci=alloc_high"... > >> > > Unfortunately I don't have a 64 bit version of Windows to test > with. Vista(32 bit) fails to even boot when docked, hot-plugging > fails to allocate resources, but at least doesn't crash. > > > > From what I've read about the (64 bit) Windows allocation stragegy > it's closer to Yinghai's method than the Linux default, preferring 64 > bit resources (>4G) when possible. I'll try to find the specification > document again. > > > Here's the host bridge info from the BIOS (from > https://bugzilla.kernel.org/show_bug.cgi?id=10461 attachment > https://bugzilla.kernel.org/attachment.cgi?id=72869): > > ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) > pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] > pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] > pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] > pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff] > pci_root PNP0A03:00: host bridge window [mem 0xe0000000-0xf7ffffff] > pci_root PNP0A03:00: host bridge window [mem 0xfc000000-0xfebfffff] > pci_root PNP0A03:00: host bridge window [mem 0xfec10000-0xfecfffff] > pci_root PNP0A03:00: host bridge window [mem 0xfed1c000-0xfed1ffff] > pci_root PNP0A03:00: host bridge window [mem 0xfed90000-0xfed9ffff] > pci_root PNP0A03:00: host bridge window [mem 0xfed40000-0xfed44fff] > pci_root PNP0A03:00: host bridge window [mem 0xfeda7000-0xfedfffff] > pci_root PNP0A03:00: host bridge window [mem 0xfee10000-0xff9fffff] > pci_root PNP0A03:00: host bridge window [mem 0xffc00000-0xffdfffff] > > There's no aperture above 4GB. So I don't think any version of > Windows will ever assign a BAR above 4GB. > -- > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > Hope have any help... Here have a document from MSDN talk about the pci allocate strategy on Windows server 2003, XP and vista: http://msdn.microsoft.com/en-us/library/windows/hardware/gg462986.aspx Per page 4, looks Microsoft have different strategy on different Windows version On XP and server 2003: First, they ignored BIOS's boot configuration and allocate below 4G. If fail, then try to allocate above 4GB. On Vista: it always respects the boot configuration of devices above 4 GB. But, this document didn't cover the behavior on Windows 7, not sure it's the same with Vista. Thanks Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
