I believe on most recent x86 boxes we can disable SCI interrupts at
the southbridge or on the CPUs local apic.
So the problem we are facing is that we have some activity while BARs
are being sized. Activity can be in the form of IRQs, DMA, IO, and
MEM accesses. And this is an important case to handle for unknown
devices. And unknown devices do not have to follow our interpretation
of the PCI spec, so we need to walk carefully and do the expected.
Question. Just how did disabling the BARs when sizing then cause
the machine to fail?
So the design should be:
- What can we do to defend ourselves and make it safe to size
a bar.
- How do we keep the window of vulnerability small if the defense
mechanisms do not work.
What I would suggest is:
- First attempt to disable IRQs, and don't do anything in the kernel.
- Second when we come to a device look to see if there is any device
specific code, for sizing or finding BARs. (For some southbridges
code to find BARs in non-standard locations would give us better
information for allocating unset BARs.)
- In the generic code disable the BARs (if it can be done safely) size
the bars and then renable the BARs to their old state.
The goal being to keep the window when uncontrolled pci accesses
can blow the system up as small as possible.
I am probably a bad one to be thinking about this problem because if a
BIOS gives me these kinds of issues, on a platform I really need to
support I port LinuxBIOS... And then their is no SMM code for me to
worry about, and all of the hardware is quiescent when the kernel is
booting...
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:30 EST