[lkml]   [2008]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

    On 1/15/2008 2:38 PM, Linus Torvalds wrote:
    > On Tue, 15 Jan 2008, Tony Camuso wrote:
    >> Linus is confident that conf1 is not going away for at least the
    >> next five years.
    > Not on PC's. Small birds tell me that there can be all these non-PC x86
    > subarchitectures that may or may not have conf1.
    > Linus

    But is there a ACPI-compliant/architecture that only offers mmconfig for
    configuration-space access and no other fallback method (i.e. no conf1,
    no bios,...)?

    2.6.24 supports mmconfig for:
    - ACPI-system with MCFG
    - a couple chipset discovered by conf1

    If a system has no conf1, but does not have e820+ACPI+MCFG, or does have
    some other method than mmconfig, it was already irrelevant in the
    discussion of Ivan's initial patch in december (because that system was
    either never supported or not impacted, and we were trying to fix bugs,
    not introduce support for new class of systems).

    Maybe Arjan could share his knowledge, and tell us what system he was
    thinking about (and whether it needed to be supported by 2.6.24) when
    "When (and I'm saying "when" not "if") systems arrive that only have
    MMCONFIG for some of the devices."

    Anyway Ivan's patch + Matthew's extensions are handling that non-PC
    arch. That combination is advocated by at least:
    Ivan Kokshaysky
    Matthew Wilcox
    Tony Camuso
    Loic Prylli
    even Arjan's said that while he prefers his patch (saying it's more
    conservative), he does not see a existing problem with the Ivan/Matthew

    [ simpler, less ambitious fixes can be forgotten if nothing can be done
    for 2.6.24, I can understand that choice ]

    The list of problems I see with Arjan's patch are:
    - no word on whether the existing Linux driver/pci/pcie/aer code should
    be converted to opt-in?
    - mmconfig still needs to be revisited to sort-out the mix of
    mmconfig+conf1+third-method access.
    - you cannot test if ext-conf-space is available without taking risks:
    when pci_enable_ext_config() is called, even legacy-conf-space is
    switched to the new method. So some administrator action (lspci -v
    +maybe-other-flag) or some driver action (that can optionally use
    ext-conf-space but does not *rely* on it) could cause some devices to
    totally disappear (if some pci hierarchy is handled by mmconfig as a
    0xffffffff section as seen on many amd machines). Matthew/Ivan will
    simply in the worst case detect that ext-conf-space is not available in
    pci_cfg_space_size()), legacy-conf-space will still work (and that
    0xffffffff section is perfectly *safe* to query, tell me if you need
    more details of why).
    - introduce a new user-api, and a new kernel API, while in practice
    there is no evidence that brings any benefits compared to Ivan/Matthew.

    IMHO, making "pci=nommconf" the default behaviour is better than
    Arjan's patch: for the exaggerated 99.99% users he claims don't need
    ext-conf-space, that's obviously as good. And many of the others would
    benefit from the ability to test and optionally use ext-conf-space is
    available without taking the risk of crashing something, so something
    else is better for them.

    With Arjan's patch, in 10 years, we might still have to use an extra
    option (or some other action) when using lspci to display extended caps,
    and we would still run the risk of crashing some old machine when doing
    so (unless maybe a blacklist of some sort will be added, making the
    newly introduced API completely useless soon, or unless we keep the
    painful bitmaps in mmconfig potentially ending-up with 3 set of pci-ops).


     \ /
      Last update: 2008-01-15 23:17    [W:0.024 / U:8.800 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site