linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Steven Newbury <steve@snewbury.org.uk>
Cc: Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	David Miller <davem@davemloft.net>,
	Tony Luck <tony.luck@intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first
Date: Wed, 6 Jun 2012 09:18:13 -0700	[thread overview]
Message-ID: <CAErSpo7BwkiVugTn9A8pM-OViRnNZ+az-pf9vjxYnd=iZ3AuSQ@mail.gmail.com> (raw)
In-Reply-To: <1338975852.5858.2.camel@Nokia-N900>

On Wed, Jun 6, 2012 at 2:44 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> On Tue,   5 Jun 2012, 06:04:57 BST, Yinghai Lu <yinghai@kernel.org> 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.

  reply	other threads:[~2012-06-06 16:18 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-23  6:34 [PATCH 00/11] PCI: resource allocation related Yinghai Lu
2012-05-23  6:34 ` [PATCH 01/11] PCI: Should add children device res to fail list Yinghai Lu
2012-05-23  6:34 ` [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first Yinghai Lu
2012-05-23 15:57   ` Linus Torvalds
2012-05-23 17:30     ` Yinghai Lu
2012-05-23 18:40       ` Yinghai Lu
2012-05-25  4:36         ` Bjorn Helgaas
2012-05-25 17:53           ` Yinghai Lu
2012-05-25 18:39             ` Yinghai Lu
2012-05-25 19:37               ` Bjorn Helgaas
2012-05-25 20:18                 ` H. Peter Anvin
2012-05-25 20:19                 ` Yinghai Lu
2012-05-25 21:55                   ` Bjorn Helgaas
2012-05-25 21:58                     ` H. Peter Anvin
2012-05-25 22:14                       ` Bjorn Helgaas
2012-05-25 23:10                     ` Yinghai Lu
2012-05-26  0:12                       ` Bjorn Helgaas
2012-05-26 15:01                         ` Bjorn Helgaas
2012-05-29 17:56                           ` Yinghai Lu
2012-05-29 17:55                         ` Yinghai Lu
2012-05-29 17:57                           ` H. Peter Anvin
2012-05-29 18:17                             ` Yinghai Lu
2012-05-29 19:03                               ` H. Peter Anvin
2012-05-29 20:46                                 ` Yinghai Lu
2012-05-29 20:50                                   ` H. Peter Anvin
2012-06-01 23:30                                     ` Yinghai Lu
2012-06-04  1:05                                       ` Bjorn Helgaas
2012-06-05  2:37                                         ` Yinghai Lu
2012-06-05  4:50                                           ` Bjorn Helgaas
2012-06-05  5:04                                             ` Yinghai Lu
2012-06-06  9:44                                               ` Steven Newbury
2012-06-06 16:18                                                 ` Bjorn Helgaas [this message]
     [not found]                                                   ` <CAGLnvc_ejMWiiubVMo7DLz5ZVn1iMbf67FB4H7crRCCTRRqt2A@mail.gmail.com>
2012-07-04  3:00                                                     ` joeyli
2012-05-29 20:53                                   ` David Miller
2012-05-29 19:23                               ` Bjorn Helgaas
2012-05-29 20:40                                 ` Yinghai Lu
2012-05-29 23:24                                   ` Bjorn Helgaas
2012-05-29 23:27                                   ` Bjorn Helgaas
2012-05-29 23:33                                     ` Yinghai Lu
2012-05-29 23:47                                       ` Bjorn Helgaas
2012-05-30  7:40                                     ` Steven Newbury
2012-05-30 16:27                                       ` Bjorn Helgaas
2012-05-30 16:30                                         ` H. Peter Anvin
2012-05-30 16:33                                         ` Linus Torvalds
2012-05-23  6:34 ` [PATCH 03/11] intel-gtt: Read 64bit for gmar_bus_addr Yinghai Lu
2012-05-23  7:21   ` Dave Airlie
2012-05-23  7:44     ` Daniel Vetter
2012-05-23  6:34 ` [PATCH 04/11] PCI: Make sure assign same align with large size resource at first Yinghai Lu
2012-05-23  6:34 ` [PATCH 05/11] resources: Split out __allocate_resource() Yinghai Lu
2012-05-23  6:34 ` [PATCH 06/11] resource: make find_resource could return just fit resource Yinghai Lu
2012-05-23  6:34 ` [PATCH 07/11] PCI: Don't allocate small resource in big empty space Yinghai Lu
2012-05-23  6:34 ` [PATCH 08/11] resource: only return range with needed align Yinghai Lu
2012-05-23  6:34 ` [PATCH 09/11] PCI: Add is_pci_iov_resource_idx() Yinghai Lu
2012-05-23  6:34 ` [PATCH 10/11] PCI: Sort unassigned resources with correct alignment Yinghai Lu
2012-05-23  6:34 ` [PATCH 11/11] PCI: Treat ROM resource as optional during assigning Yinghai Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAErSpo7BwkiVugTn9A8pM-OViRnNZ+az-pf9vjxYnd=iZ3AuSQ@mail.gmail.com' \
    --to=bhelgaas@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=steve@snewbury.org.uk \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).