[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a65d005c2c7607d4d6dd6e280fdc6d66.squirrel@www.zytor.com>
Date: Mon, 26 Apr 2010 14:12:35 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: "Jesse Barnes" <jbarnes@...tuousgeek.org>
Cc: "Bjorn Helgaas" <bjorn.helgaas@...com>,
"Andy Isaacson" <adi@...apodia.org>,
"R. Andrew Bailey" <bailey@...mai.com>,
"Yinghai" <yinghai.lu@...cle.com>,
"H. Peter Anvin" <hpa@...or.com>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Ingo Molnar" <mingo@...hat.com>, guenter.roeck@...csson.com,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Thomas Renninger" <trenn@...e.de>, yaneti@...lera.com
Subject: Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below
BIOS_END
> On Mon, 26 Apr 2010 14:27:56 -0600
> Bjorn Helgaas <bjorn.helgaas@...com> wrote:
>> I'm a little concerned that those patches are a sledgehammer approach.
>> Previously, IORESOURCE_BUSY has basically been used for mutual exclusion
>> between drivers that would otherwise claim the same resource. It hasn't
>> been used to guide resource assignment in the PCI/PNP/etc core. Maybe
>> it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure.
>> Right now it feels like undesirable overloading to me.
>
> I guess that's true, removing those regions from the pool entirely
> might be better? Or some other, clear way of expressing that the
> regions aren't available to drivers. Maybe we need a new IO resource
> type for platform ranges.
>
>> I think it also leads to at least one problem: Guenter's machine has no
>> VGA but has a PCI device that lives at 0xa0000. The driver for that
>> device won't be able to request that region if the arch code has marked
>> it busy.
>
> Ah good point, so we'll want another approach at any rate. Yinghai?
What we need is to keep track of the areas available for address space
allocation by dynamically addressed devices, as distinct from address
space that is in use by a kernel-known device. There is an in-between,
which one can call "here there be dragons" space, which should never be
used for dynamic device allocation, but if a platform device or
pre-assigned device uses that space then it should be allowed to be
allocated.
In the case of x86, anything that is E820_RESERVED, *or* in the legacy
region (below 1 MB) and is not RAM, is "here there be dragons" space.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists