Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S265008AbSLUV7Z>; Sat, 21 Dec 2002 16:59:25 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S265065AbSLUV7Z>; Sat, 21 Dec 2002 16:59:25 -0500
Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:17965 "EHLO
	frodo.biederman.org") by vger.kernel.org with ESMTP
	id <S265008AbSLUV7X>; Sat, 21 Dec 2002 16:59:23 -0500
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
References: <15874.58889.846488.868570@napali.hpl.hp.com>
	<Pine.LNX.4.44.0212200849090.2035-100000@home.transmeta.com>
	<15875.24790.221094.202859@napali.hpl.hp.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: 21 Dec 2002 15:06:50 -0700
In-Reply-To: <15875.24790.221094.202859@napali.hpl.hp.com>
Message-ID: <m17ke3m3gl.fsf@frodo.biederman.org>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3317
Lines: 72

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
-
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/