[lkml]   [2012]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first
    On Tue, May 29, 2012 at 12:23 PM, Bjorn Helgaas <> wrote:
    > On Tue, May 29, 2012 at 12:17 PM, Yinghai Lu <> wrote:
    >> On Tue, May 29, 2012 at 10:57 AM, H. Peter Anvin <> wrote:
    >>> On 05/29/2012 10:55 AM, Yinghai Lu wrote:
    >>>> x86 are using 16bits.
    >>>> some others use 32 bits.
    >>>> #define IO_SPACE_LIMIT 0xffffffff
    >>>> ia64 and sparc are using 64bits.
    >>>> #define IO_SPACE_LIMIT               0xffffffffffffffffUL
    >>>> but pci only support 16bits and 32bits.
    >>>> maybe later we can add
    >>>> PCI_MAX_RESOURCE_16
    >>>> to handle 16bits and 32bit io ports.
    >>> Shouldn't this be dealt by root port apertures?
    >> pci bridge could support 16bits and 32bits io port.
    >> but we did not record if 32bits is supported.
    >> so during allocating, could have allocated above 64k address to non
    >> 32bit bridge.
    >> but  x86 is ok, because ioport.end always set to 0xffff.
    >> other arches with IO_SPACE_LIMIT with 0xffffffff or
    >> 0xffffffffffffffffUL may have problem.
    > I think current IO_SPACE_LIMIT usage is a little confused.  The
    > "ioport_resource.end = IO_SPACE_LIMIT" in kernel/resource.c refers to
    > a CPU-side address, not a bus address.  Other uses, e.g., in
    > __pci_read_base(), apply it to bus addresses from BARs, which is
    > wrong.  Host bridges apply I/O port offsets just like they apply
    > memory offsets.  The ia64 IO_SPACE_LIMIT of 0xffffffffffffffffUL means
    > there's no restriction on CPU-side I/O port addresses, but any given
    > host bridge will translate its I/O port aperture to bus addresses that
    > fit in 32 bits.
    > None of this is really relevant to the question I asked, namely, "why
    > Yinghai's patch doesn't limit I/O BAR values to 32 bits?"  That
    > constraint is clearly a requirement because I/O BARs are only 32 bits
    > wide, but I don't think it needs to be enforced in the code here.  The
    > host bridge or upstream P2P bridge apertures should already take care
    > of that automatically.  I don't think the 16- or 32-bitness of P2P
    > bridge apertures is relevant here, because the I/O resources available
    > on the secondary bus already reflect that.
    > After all that discussion, I think my objection here boils down to
    > "you shouldn't change the I/O BAR constraints in a patch that claims
    > to allocate 64-bit *memory* BARs above 4GB."
    > I think the code below is still the clearest way to set the constraints:
    >   if (res->flags & IORESOURCE_MEM_64) {
    >       start = (resource_size_t) (1ULL << 32);
    >       end = PCI_MAX_RESOURCE;
    >   } else {
    >       start = 0;
    >       end = PCI_MAX_RESOURCE_32;
    >   }
    > It's not strictly necessary to limit I/O BARs to PCI_MAX_RESOURCE_32
    > because host bridge apertures should already enforce that, but I think
    > the code above just makes it clearer.

    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


    [unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream]
     \ /
      Last update: 2012-05-29 23:01    [W:0.054 / U:16.552 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site