> > Some Intel chipsets lockup when reading the whole configuration space
> > AFAIR: using od or lspci -xx on /proc/bus/pci/... is not always safe from
> > a root account. From non root accounts, you can only read the first 64
> > bytes of config space, which has been safe on all devices until now, but
> > cannot even been guaranteed in the future given the general tendency to
> > violate PCI specs in new and innovative ways :-)
>
> PCI specs require device to support 256 byte of config space, 64 bytes
> for the predefined header and the rest being device specific.
> If the PCI specs say that the device specific region can be read without
> any side effects, then these devices are not PCI compliant. Does they?
I'm not sure about what the PCI spec says about side effects. Having read
side effect for something called a configuration space looks weird but
would perhaps be acceptable. However the PCI configuration space is mostly
designed to do one thing as its name indicates: to configure the system at
initialization time (or insertion time with hot plugging), as such the
accesses are quite slow, in most cases using an indirect access method
through a couple of dedicated I/O registers whose access must be
serialized through a spinlock on SMP, and thererefore are totally unsuited
for performance critical operations (registers accessed for device
operation which I'll call run time registers).
Note that there are examples of chips which only have configuration space
and no memory or I/O space access like the memory controller for quad PPro
(450GX/KX IIRC). This makes perfect sense since most run time registers
are used to report ECC errors: you'd better not need to access these
registers too often, and they have no side effects (a bit is set to flag
an error and you explicitly clear it by writing a 1). So devices with
configuration space only are perfectly valid IMHO for these kind of non
performance critical things (ECC error reports, Power mangament,
etc...), provided they are designed according to sane guidelines.
OTOH read registers with side effects, like reading a FIFO buffer, are in
general absolutely performance critical. So if a register is performance
critical, it is wrong to access it through the configuration space and it
would even be better not to map it there. Thus for configuration
space I prefer registers which requires an explicit acknowledge cycle
with a read/write one to clear flag.
However the worst case is that some chips manage to lockup the whole PCI
bus (and hence the system) when reading from some configuration registers.
This is a clear violation of the PCI spec and a very serious one.
Finally you should not forget the conclusion I reached: you can only
trigger this from root. So is is not a security problem and does not
require any patch (unless I missed something). I did not notice any
data corruption but perhaps I was lucky.
> PCI specifications violations are quite common not only from hardware.
> Sometimes you are required to do so from a device driver in order to work
> around chip bugs, sometimes you just want your driver or hardware to be
> faster.
Yes, but this type of things is unlikely to require frequent accesses to
configuration space registers. This space is designed to be essentially
safe to access, although maybe slow and I personnally hate side effects in
this area. I prefer to be able to type lspci -xx when looking for PCI
problems or debugging a driver (although in the last case I rather use
lspci -xx -s device).
> I am wondering about PCI systems working so well and being so much
> violated at the same time. :-)
I wonder, too :-)
Regards,
Gabriel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/