From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Bjorn Helgaas" <bjorn.helgaas@hp.com>,
"Andy Isaacson" <adi@hexapodia.org>,
"R. Andrew Bailey" <bailey@akamai.com>,
"Yinghai" <yinghai.lu@oracle.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
guenter.roeck@ericsson.com,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Thomas Renninger" <trenn@suse.de>,
yaneti@declera.com
Subject: Re: [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END
Date: Mon, 26 Apr 2010 17:05:47 -0700 [thread overview]
Message-ID: <20100426170547.5d7daa47@virtuousgeek.org> (raw)
In-Reply-To: <a96459c7f3573eef81dd6d6c4e3dedd8.squirrel@www.zytor.com>
On Mon, 26 Apr 2010 16:49:55 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:
> > Sorry, sounds like we're talking about a few different things here:
> > 1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
> > 2) devices which sit in e820 ram or other space below 1M
> > 3) how to hand out space from the 0-1M region
> >
> > Bjorn's patch fixes (3) so that regular PCI devices don't get space
> > there, which makes sense.
> >
> > Some devices may be in the special region, but were pointed there by
> > the BIOS. Generally this should be ok, so drivers requesting this
> > space should be allowed to get at it, but we should avoid putting
> > anything else there.
> >
> > And below it sounds like you're talking about (1). If so, then yes I
> > guess we need a solution there, which will allow drivers to bind to
> > these "reserved" devices, even though the BIOS has marked them as off
> > limits, at least as far as e820 goes.
> >
> > So perhaps both (1) and (2) could be put into a new, special IO
> > resource space, or could use a new flag, since "busy" doesn't really
> > reflect what's going on there very well, as Bjorn pointed out.
> >
> > Jesse
>
> Properly done, these aren't separate cases at all.
>
> The E820 interface as specified doesn't reserve the address space below 1
> MB, because it is legacy space -- which is another way of saying "everyone
> already knows to reserve it." The Right Thing[TM] to do is simply to
> modify the data output by E820 to reserve all non-memory space below 1 MB;
> this can (and should) be done in platform-specific initialization code to
> allow overrides.
>
> Once that is done, both your (2) and (3) cases are nothing but special
> subcases of (1). That's what I would like to see as the right solution,
> but it is clearly too late to do that in .34.
>
> Bjorn's solution is very attractive for .34 since it is so simple, but
> it's not a complete solution.
Glad we agree. As I said (and echoing Bjorn), I think it would be best
to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
We want and need to do allocations from the special region, so we
should mark it as such.
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2010-04-27 0:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-26 23:02 [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END H. Peter Anvin
2010-04-26 23:25 ` Jesse Barnes
2010-04-26 23:49 ` H. Peter Anvin
2010-04-26 23:49 ` H. Peter Anvin
2010-04-27 0:05 ` Jesse Barnes [this message]
2010-04-27 1:27 ` Linus Torvalds
2010-04-27 1:40 ` Jesse Barnes
2010-04-27 1:41 ` Yinghai
2010-04-27 15:11 ` Bjorn Helgaas
2010-04-28 16:07 ` Bjorn Helgaas
2010-04-28 17:14 ` Yinghai Lu
2010-04-28 19:06 ` Bjorn Helgaas
2010-04-28 19:10 ` Yinghai
2010-04-28 19:23 ` Bjorn Helgaas
-- strict thread matches above, loose matches on Subject: below --
2010-04-27 2:02 H. Peter Anvin
2010-04-13 21:42 [PATCH -v2 1/2] x86: Reserve [0xa0000, 0x100000] in e820 map Yinghai
2010-04-21 5:33 ` [PATCH -v4 1/3] " Yinghai
2010-04-21 19:31 ` Andy Isaacson
2010-04-23 23:05 ` [PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END Bjorn Helgaas
2010-04-23 23:44 ` H. Peter Anvin
2010-04-24 0:36 ` Yinghai Lu
2010-04-26 12:50 ` R. Andrew Bailey
2010-04-26 15:40 ` Bjorn Helgaas
2010-04-26 18:34 ` Andy Isaacson
2010-04-26 19:31 ` Jesse Barnes
2010-04-26 20:27 ` Bjorn Helgaas
2010-04-26 20:37 ` Jesse Barnes
2010-04-26 21:07 ` Yinghai
2010-04-26 21:19 ` H. Peter Anvin
2010-04-26 21:12 ` H. Peter Anvin
2010-04-26 21:25 ` Jesse Barnes
2010-04-26 21:44 ` H. Peter Anvin
2010-04-26 21:53 ` Jesse Barnes
2010-04-26 21:59 ` Yinghai Lu
2010-04-26 21:44 ` jacob pan
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=20100426170547.5d7daa47@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=adi@hexapodia.org \
--cc=bailey@akamai.com \
--cc=bjorn.helgaas@hp.com \
--cc=guenter.roeck@ericsson.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=trenn@suse.de \
--cc=x86@kernel.org \
--cc=yaneti@declera.com \
--cc=yinghai.lu@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.