lkml.org 
[lkml]   [2012]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first
    On Wed, May 30, 2012 at 1:40 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > On 30/05/12 00:27, Bjorn Helgaas wrote:
    >> On Tue, May 29, 2012 at 2:40 PM, Yinghai Lu <yinghai@kernel.org>
    >> wrote:
    >>> On Tue, May 29, 2012 at 12:23 PM, Bjorn Helgaas
    >>> <bhelgaas@google.com> wrote:
    >>>> On Tue, May 29, 2012 at 12:17 PM, Yinghai Lu
    >>>> <yinghai@kernel.org> wrote:
    >>>>> On Tue, May 29, 2012 at 10:57 AM, H. Peter Anvin
    >>>>> <hpa@zytor.com> wrote:
    >>>>>> On 05/29/2012 10:55 AM, Yinghai Lu wrote:
    >
    > *SNIP*
    >
    >>>
    >>>
    >>> ok, please check the version, that put back PCI_MAX_RESOURCE_32
    >>> for io ports.
    >>>
    >>> also RFC to limit for 16 bit ioport handling.  only help other
    >>> arches that does support 32bit ioports but have bridges only
    >>> support 16bit io ports.
    >>
    >> I don't understand this one at all.  It looks like you mashed
    >> together at least two changes: (1) prefer I/O space above 64K if
    >> available, and (2) mark secondary bus resources with
    >> IORESOURCE_IO_32 when the P2P bridge I/O window address decode type
    >> is PCI_IO_RANGE_TYPE_32 and use that to limit allocations.
    >>
    >> I don't see the justification for (1).  What problem does this
    >> solve?
    >>
    > I can potentially see this helping with hotplug, where a new device
    > has only 16 bit io ports, but if there's no space remaining under 64k
    > allocation would fail.  Preferring above 64k means preserving that
    > limited resource.  This is exactly equivalent to my original
    > motivation for preferring 64 bit PCI mem in order to preserve 32 bit
    > address space for hotplug devices without 64 bit BARs.

    You're right, the spec does allow the upper 16 bits of I/O BARs to be
    hardwired to zero (PCI spec rev 3.0, p. 226), so this part does make
    some sense. I don't think it applies to x86, since I don't think
    there's a way to generate an I/O access to anything above 64K, but it
    could help other arches.

    I'm inclined to be conservative and wait until we find a problem where
    a patch like this would help.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-05-30 19:01    [from the cache]
    ©2003-2014 Jasper Spaans. Advertise on this site