From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: mingo@kernel.org, intel-gfx@lists.freedesktop.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, tglx@linutronix.de,
torvalds@linux-foundation.org
Subject: Re: Ugly patches for stolen reservation
Date: Fri, 26 Jul 2013 08:33:14 -0700 [thread overview]
Message-ID: <20130726083314.4e2e333f@jbarnes-desktop> (raw)
In-Reply-To: <51F1ED8F.40703@zytor.com>
On Thu, 25 Jul 2013 20:31:27 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:
> On 07/25/2013 07:14 PM, Jesse Barnes wrote:
> > To clarify: it'll either be marked reserved or not listed at all in e820, which is why I did this early, before any other e820 stuff like the "RAM buffer" are allocated, and before we could use the iomem resource (or maybe we could even early per Linus? I'll check).
> >
> > Jesse
>
> If it is marked reserved or not listed at all it is much less of an
> issue. Reserved is in fact the correct thing; not listed at all really
> isn't very problematic in most cases.
Yeah the problems seem to fall into two categories:
1) mmio space is allocated in this range:
https://bugs.freedesktop.org/show_bug.cgi?id=66726
2) range gets partially allocated to the "RAM buffer"
https://bugs.freedesktop.org/show_bug.cgi?id=66844
Case (1) is the one that worries me. I'm guessing it'll mainly be a
problem on machines where MMIO space is limited or somehow structured
such that PCI resources end up there when we allocate them. Depending
on what gets put there and the decode priority, behavior may be poor.
Case (2) isn't harmful, but ends up causing our driver to skip stolen
memory initialization, because of the conflict.
Anyway I'll look at Linus's suggestion of reserving in the iomem
resource really early and roll in Chris's stuff if that doesn't work
out.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2013-07-26 15:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <rddfy5e894xuv6d47gu7hbuh.1374804892449@email.android.com>
2013-07-26 3:31 ` Ugly patches for stolen reservation H. Peter Anvin
2013-07-26 15:33 ` Jesse Barnes [this message]
2013-07-26 20:24 ` Ingo Molnar
2013-07-26 20:28 ` H. Peter Anvin
2013-07-26 20:45 ` [Intel-gfx] " Daniel Vetter
2013-07-25 16:37 Jesse Barnes
2013-07-25 20:05 ` Ingo Molnar
2013-07-25 20:16 ` Jesse Barnes
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 15:51 ` Jesse Barnes
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=20130726083314.4e2e333f@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