From: Andi Kleen <andi@firstfloor.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@elte.hu>,
torvalds@osdl.org, tglx@linutronix.de,
linux-kernel@vger.kernel.org, ying.huang@intel.com
Subject: Re: [PATCH] Fix left over EFI cache mapping problems
Date: Fri, 15 Feb 2008 00:01:38 +0100 [thread overview]
Message-ID: <20080214230138.GA1014@basil.nowhere.org> (raw)
In-Reply-To: <20080214140816.68b47407@laptopd505.fenrus.org>
On Thu, Feb 14, 2008 at 02:08:16PM -0800, Arjan van de Ven wrote:
> On Thu, 14 Feb 2008 22:42:41 +0100
> Andi Kleen <andi@firstfloor.org> wrote:
>
> > On Thu, Feb 14, 2008 at 07:38:19PM +0100, Ingo Molnar wrote:
> > >
> > > * Andi Kleen <andi@firstfloor.org> wrote:
> > >
> > > > > this is indeed a bug (we change the attributes for a larger
> > > > > area than needed), but your fix is unclean. Find below a
> > > > > cleaner solution.
> > > >
> > > > You're still ignoring the other problem of set_memory_uc() not
> > > > handling fixmap and ioremap correctly. [...]
> > >
> > > No, we did not ignore it, and yes, you are wrong.
> > >
> > > One thing that you miss is that the 64-bit EFI runtime has to be
> > > marked uncacheable only if it the EFI image attribute signals an
> > > uncacheable area:
> > >
> > > if (!(md->attribute & EFI_MEMORY_WB))
> > > set_memory_uc(md->virt_addr, md->num_pages);
> > >
> > > and Linux EFI does not support device EFI runtimes. So your
> > > observation,
> >
> > Sorry I didn't get that (you were a bit terse).
> >
> > You're saying the EFI BIOSes will never set that flag ?
> >
> > I'm reading page 123+ of UEFI 2.1 which describes GetMemoryMap()
> > and these flags and I see nothing to that effect. I admit I didn't
> > read the full EFI bible so far so there are certainly EFI
> > aspects I don't understand.
> >
> > Can you please clarify why EFI would not set that flag on Linux?
>
> because it will only normally
normally or guaranteed?
e.g. possible scenario: one of the EFI runtime services needs
access to some device to do something (e.g. for rebooting
or putting information into the battery backed RAM). Wouldn't they likely
provide a UC mapping to that device's memory using this flag?
> get set on EFI code that lives in device memory.
Ok but what prevents the firmware from passing such memory areas?
I assume it doesn't know that Linux doesn't need such mappings, does it?
Anyways if all the questions above get firmly answered with no then the code
setting mappings UC should be definitely removed. I would welcome such
a patch.
-Andi
next prev parent reply other threads:[~2008-02-14 23:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-14 13:13 [PATCH] Fix left over EFI cache mapping problems Andi Kleen
2008-02-14 16:12 ` Ingo Molnar
2008-02-14 17:16 ` Andi Kleen
2008-02-14 18:38 ` Ingo Molnar
2008-02-14 21:42 ` Andi Kleen
2008-02-14 22:08 ` Arjan van de Ven
2008-02-14 23:01 ` Andi Kleen [this message]
2008-02-15 2:52 ` Huang, Ying
2008-02-15 8:55 ` Andi Kleen
2008-02-15 9:16 ` Huang, Ying
2008-02-15 4:48 ` Huang, Ying
2008-02-15 5:44 ` Linus Torvalds
2008-02-15 6:24 ` Huang, Ying
2008-02-15 7:30 ` Ingo Molnar
2008-02-15 7:08 ` Ingo Molnar
2008-02-15 7:32 ` Huang, Ying
2008-02-18 1:53 ` Huang, Ying
2008-02-18 11:26 ` Andi Kleen
2008-02-18 14:05 ` Ingo Molnar
2008-02-15 8:48 ` Andi Kleen
2008-02-15 9:21 ` Huang, Ying
2008-02-15 9:43 ` Andi Kleen
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=20080214230138.GA1014@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@osdl.org \
--cc=ying.huang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox