From: ebiederm@xmission.com (Eric W. Biederman)
To: davidm@hpl.hp.com
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: PATCH 2.5.x disable BAR when sizing
Date: 21 Dec 2002 15:06:50 -0700 [thread overview]
Message-ID: <m17ke3m3gl.fsf@frodo.biederman.org> (raw)
In-Reply-To: <15875.24790.221094.202859@napali.hpl.hp.com>
David Mosberger <davidm@napali.hpl.hp.com> writes:
> >>>>> On Fri, 20 Dec 2002 09:05:53 -0800 (PST), Linus Torvalds
> <torvalds@transmeta.com> said:
>
>
> 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.
Actually it is not quite as bad as that.
- We can reasonably assume there are no pci to pci transactions going
on, so the only accesses to a pci resource are generated by the
kernel from printk.
- If the large device is behind a pci bridge it should be shielded
from the chaos.
- If we don't call printk until we restore the old BAR value (which
is currently the case (drivers/pci/probe.c:60)) there should be no
transactions on the pci bus, that get a conflicting routing.
So it is safe because it is very, very local operation.
>
> 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.
Actually we just need to be careful and not turn on the light
in the room. (I.e. keep the pci bus otherwise quiet while we are
sizing a bar).
> 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.
As long as the pci bus is quiet while we are sizing a bar the current
method safe.
Eric
next prev parent reply other threads:[~2002-12-21 21:59 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-19 21:37 PATCH 2.5.x disable BAR when sizing Grant Grundler
2002-12-20 2:54 ` Alan Cox
2002-12-20 2:27 ` David Mosberger
2002-12-20 6:05 ` Linus Torvalds
2002-12-20 19:50 ` Grant Grundler
2002-12-20 20:14 ` Linus Torvalds
2002-12-20 21:22 ` Grant Grundler
2002-12-21 18:34 ` Maciej W. Rozycki
2002-12-20 20:37 ` Richard B. Johnson
2002-12-20 21:29 ` Grant Grundler
2002-12-20 5:57 ` Linus Torvalds
2002-12-20 9:42 ` David Mosberger
2002-12-20 12:53 ` Ivan Kokshaysky
2002-12-20 17:05 ` Linus Torvalds
2002-12-20 18:26 ` David Mosberger
2002-12-20 19:28 ` Linus Torvalds
2002-12-21 22:06 ` Eric W. Biederman [this message]
2002-12-21 22:44 ` Linus Torvalds
2002-12-22 7:15 ` Paul Mackerras
2002-12-22 15:03 ` Benjamin Herrenschmidt
2002-12-22 19:21 ` Ivan Kokshaysky
2002-12-23 0:29 ` Paul Mackerras
2002-12-23 15:26 ` Ivan Kokshaysky
2003-01-05 12:37 ` [patch 2.5] PCI: allow alternative methods for probing the BARs Ivan Kokshaysky
2003-01-06 0:29 ` Anton Blanchard
2003-01-06 4:14 ` Linus Torvalds
2003-01-06 5:22 ` Eric W. Biederman
2003-01-06 10:31 ` Benjamin Herrenschmidt
2003-01-06 11:32 ` Andrew Walrond
2003-01-06 22:01 ` Grant Grundler
2003-01-06 19:45 ` Grant Grundler
2003-01-07 17:05 ` Ivan Kokshaysky
2003-01-07 17:46 ` Linus Torvalds
2003-01-07 20:17 ` Grant Grundler
2003-01-08 14:47 ` Ivan Kokshaysky
2003-01-08 22:34 ` Grant Grundler
2003-01-06 15:33 ` Ivan Kokshaysky
2003-01-06 21:52 ` Grant Grundler
2003-01-06 23:19 ` Linus Torvalds
2003-01-07 0:13 ` Grant Grundler
2003-01-07 12:33 ` Alan Cox
2003-01-07 17:27 ` Ivan Kokshaysky
2003-01-07 18:46 ` Alan Cox
2003-01-07 17:44 ` Linus Torvalds
2003-01-08 16:55 ` Ivan Kokshaysky
2003-01-09 17:46 ` [patch 2.5] 2-pass PCI probing, generic part Ivan Kokshaysky
2003-01-09 17:52 ` Benjamin Herrenschmidt
2003-01-09 22:09 ` Ivan Kokshaysky
2003-01-09 22:16 ` Linus Torvalds
2003-01-09 22:26 ` Benjamin Herrenschmidt
2003-01-10 3:49 ` Alan Cox
2003-01-09 23:19 ` Ivan Kokshaysky
2003-01-09 23:35 ` Linus Torvalds
2003-01-10 1:09 ` Grant Grundler
2003-01-10 7:56 ` Eric W. Biederman
2003-01-10 19:00 ` Grant Grundler
2003-01-10 21:42 ` Ivan Kokshaysky
2003-01-10 23:07 ` Grant Grundler
2003-01-11 19:39 ` Scott Murray
2003-01-12 7:19 ` Greg KH
2003-01-13 6:28 ` Scott Murray
2003-01-10 13:35 ` Ivan Kokshaysky
2003-01-14 16:39 ` Ivan Kokshaysky
2003-01-09 18:36 ` David Mosberger
2003-01-09 19:52 ` Grant Grundler
2003-01-09 22:40 ` Ivan Kokshaysky
2003-01-09 17:48 ` [patch 2.5] 2-pass PCI probing, hotplug changes Ivan Kokshaysky
2003-01-09 17:51 ` [patch 2.5] 2-pass PCI probing, i386 USB quirk Ivan Kokshaysky
2003-01-07 17:12 ` [patch 2.5] PCI: allow alternative methods for probing the BARs Ivan Kokshaysky
2003-01-07 17:06 ` Ivan Kokshaysky
2002-12-22 19:51 ` PATCH 2.5.x disable BAR when sizing Linus Torvalds
2002-12-22 19:57 ` Eric W. Biederman
2002-12-22 10:38 ` Eric W. Biederman
2002-12-22 18:39 ` Ivan Kokshaysky
2002-12-22 19:47 ` Eric W. Biederman
2002-12-22 21:05 ` Ivan Kokshaysky
2002-12-20 18:50 ` Ivan Kokshaysky
2002-12-20 19:11 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m17ke3m3gl.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=davidm@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox