Linus> On Fri, 20 Dec 2002, David Mosberger wrote:
>> Could you please stop this ia64 paranoia and instead explain to
>> me why it's OK to relocate a PCI device to
>> (0x100000000-PCI_dev_size) temporarily? That just seems horribly
>> unsafe to me.
Linus> No. It's not horribly unsafe at all. It's very safe, for one
Linus> simple reason: it's how PCI probing has _always_ been
Linus> done. Exactly because the alternatives simply do not work.
Linus> I can also tell you why it does work, and why it's supposed
Linus> to work: by writing 0xffffffff to the BAR register, you
Linus> basically move the BAR to high PCI memory - even if it was
Linus> enabled before. Which is fine, as long as nobody else is in
Linus> that high memory. So the secondary rule to "don't turn off
Linus> MEM or IO accesses" is "never allocate real PCI BAR resources
Linus> at the top of memory".
A 32-bit PCI device can decode up to 2GB of memory. I doubt any PC
firmware is reserving the top 2GB for BAR-sizing. Without a
reasonably small a-priori limit on the address window size of device,
this method isn't safe.
Linus> Let me re-iterate the "turn power off at the master switch in
Linus> a house when switching a light bulb" analogy. Yes, it's a
Linus> good idea if you are nervous, but you do that only when you
Linus> _know_ who is in the house and you know what they are doing
Linus> and it's ok by them.
That's a poor analogy. What you're suggesting is more like replacing
the light bulb while it's powered on. Yes, it can be done, but people
do get burned and electrocuted that way.
Linus> One solution in the long term may be to not even probe the
Linus> BAR's at all in generic code, and only do it in the
Linus> pci_enable_dev() stuff. That way it would literally only be
Linus> done by the driver, who can hopefully make sure that the
Linus> device is ok with it.
Yes, I see now that the method in the PCI spec isn't really safe
either, so BAR-sizing probably shouldn't be done in generic code at
all.
--david
-
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/