lkml.org 
[lkml]   [2007]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue


    On Mon, 24 Dec 2007, Jeff Garzik wrote:
    >
    > Definitely. So, two questions:
    >
    > What's the preferred way to deal with the desire to view extended config space
    > with "lspci -vvvxxx"?

    Well, there's two issues right now with MMCONFIG

    - we've hit various bugs in it. The bugs are admittedly very rare, but
    they are really painful when they happen.

    This is the more "fundamental" of the problems, and this is the one
    that means that on some machines, the answer to the above question will
    simply *always* be that we simply will never *ever* show the extended
    config space - because even though it might work, we are going to
    decide that it's simply too dangerous.

    (Hypothetical example: we might, for example, end up saying that we
    will simply never enable mmconfig at all unless the BIOS DMI date says
    that the motherboard was built in 2008 or later)

    - the (currently more common) problem that our initial probing is totally
    screwed up with mmconfig.

    This is the thing that causes *most* of our current problems, and the
    fact is, we absolutely cannot do the initial kernel PCI probing using
    mmconfig accesses. Not only do we not have enough information about the
    resources yet at that stage to decide sanely whether mmconfig can
    really work, but it is my sincere hope that some day the mmconfig MMIO
    region itself will be defined by some standard BAR etc, so trying to
    probe the BARs using mmconfig would be a chicken-and-egg problem.

    There's also the issue that we want to often *validate* the mmconfig
    address using config space accesses, and right now we have some really
    ugly code that actually uses "pci_conf1_read()" _explicitly_ to avoid
    using mmconfig for this (see arch/x86/pci/mmconfig-shared.c).

    The *second* problem is entirely a kernel internal issue. It's the one
    that causes us the biggest issues right now, but it's also the one that
    will not impact user space at all once if is fixed. So once we do the
    *early* probing using anything but mmconfig accesses, we can then much
    more easily enable mmconfig later, and by the time the user does anything
    like "lspci -vvvxxxx", we could do those mmconfig accesses.

    I also suspect that we *may* want to use a separate file for the extended
    config. Right now, things like lspci read the config space by accessing
    a file like

    /sys/bus/pci/devices/0000:00:00.0/config

    and I'm not at all sure we want to extend that one past the first 256
    bytes of config space. Why? Because I don't want old programs that may not
    know how dangerous the rest of the space is to read extended config space
    by mistake when they don't know how to parse it anyway.

    So I would *suggest* (but this may be overly cautious) that we at least
    consider forcing people who actually want to read extended config space to
    have to use a separate file for it ("/sys/.../extended-config"), because
    that would then also be a sign to the kernel that "ok, the user really
    asked for us to use mmconfig cycles here".

    > Is there a path for hw vendors, after passing 1,001 anal checks, to maintain
    > the current behavior as it exists today in arch/x86/pci/mmconfig_{32,64}.c?

    Well, the *current* behaviour as far as setup is concerned is
    unacceptable. But yes, longer term, we should be able to just have quirk
    entries for saying "enable mmconfig because I know it's safe", except we
    should not enable them until after the core PCI probing has completed.

    Linus


    \
     
     \ /
      Last update: 2007-12-24 19:55    [W:2.543 / U:0.292 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site