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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
