From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Ugly patches for stolen reservation
Date: Fri, 26 Jul 2013 08:51:58 -0700 [thread overview]
Message-ID: <20130726085158.56724801@jbarnes-desktop> (raw)
In-Reply-To: <CA+55aFyDXkvc7mK2trfHA2Wj9vRu2FkCeZuZVfRvmbak1TqUmA@mail.gmail.com>
On Thu, 25 Jul 2013 17:31:29 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > So the bootloader is just as likely to step on things... what happens when/if it does?
>
> This isn't a new problem. We've had this "firmware tables don't show
> all devices" issue before.
>
> The only odd thing about this one is how the quirk in question uses
> "e820_add_region()" instead of just adding things to the MMIO list.
> And I think that's actually likely a mistake.
>
> So Jesse, why don't you do what the other quirks do, and claim an
> actual MMIO resource? If you make it a real resource, you'll get to
> use fancy things like REAL NAMES, and actually document it. With
> human-readable strings.
>
> See quirk_io_region() in drivers/pci/quirks.c for example. The same
> code except for IORESOURCE_MEM should do a lovely job..
>
> And even *if* it's already marked reserved in the e820 table, it just
> looks nice in /proc/iomem.
>
> Hmm?
I should have mentioned yesterday that we *do* try to reserve the
resource in our driver init, with pretty name and everything.
The issue here is making sure we are actually *able* to reserve it
without conflicts at driver init time.
If the PCI layer has put something there (misc MMIO or the "RAM
buffer" intended to prevent stuff like this) because it's not listed in
the E820 map, we'll fail to get at this memory in our driver init.
Thus the early reservation in early-quirks, followed by a real
request_mem_region later on.
Doing the request_mem_region before the PCI layer gets its hands on it
isn't really possible, because __request_region depends on the memory
allocator being initialized. So rather than add a new hook elsewhere in
setup_arch or start_kernel I figured I'd use an early quirk.
Reasonable? Note iomem in both cases.
Before (RAM buffer prevents our allocation):
cafff000-caffffff : System RAM
cb000000-cbffffff : RAM buffer
cfa00000-feafffff : PCI Bus 0000:00
d0000000-dfffffff : 0000:00:02.0
After (yay):
cb000000-cb9fffff : RAM buffer
cba00000-cf9fffff : reserved
cba00000-cf9fffff : Graphics Stolen Memory
cfa00000-feafffff : PCI Bus 0000:00
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2013-07-26 15:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 16:37 Jesse Barnes
2013-07-25 16:37 ` [PATCH 1/2] drm/i915: split PCI IDs out into i915_drm.h v3 Jesse Barnes
2013-07-25 23:06 ` Chris Wilson
2013-07-25 16:37 ` [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3 Jesse Barnes
2013-07-25 22:42 ` Chris Wilson
2013-07-25 22:59 ` Chris Wilson
2013-07-25 23:18 ` Jesse Barnes
2013-07-26 8:10 ` [Intel-gfx] " Daniel Vetter
2013-07-26 16:58 ` H. Peter Anvin
2013-07-26 17:12 ` Jesse Barnes
2013-07-25 20:05 ` Ugly patches for stolen reservation Ingo Molnar
2013-07-25 20:16 ` Jesse Barnes
2013-07-25 22:10 ` [Intel-gfx] " Daniel Vetter
2013-07-25 22:42 ` H. Peter Anvin
2013-07-25 23:17 ` Jesse Barnes
2013-07-26 0:49 ` H. Peter Anvin
2013-07-26 0:31 ` Linus Torvalds
2013-07-26 0:48 ` H. Peter Anvin
2013-07-26 17:52 ` [Intel-gfx] " Daniel Vetter
2013-07-26 15:51 ` Jesse Barnes [this message]
[not found] <rddfy5e894xuv6d47gu7hbuh.1374804892449@email.android.com>
2013-07-26 3:31 ` H. Peter Anvin
2013-07-26 15:33 ` Jesse Barnes
2013-07-26 20:24 ` Ingo Molnar
2013-07-26 20:28 ` H. Peter Anvin
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=20130726085158.56724801@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=hpa@zytor.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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
Powered by JetHome