All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Jack Steiner <steiner@sgi.com>,
	mingo@elte.hu, tglx@linutronix.de, lenb@kernel.org,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] - Mapping ACPI tables as CACHED
Date: Tue, 24 Aug 2010 14:39:27 -0700	[thread overview]
Message-ID: <4C743C0F.2010101@zytor.com> (raw)
In-Reply-To: <20100724001449.GA9618@khazad-dum.debian.net>

On 07/23/2010 05:14 PM, Henrique de Moraes Holschuh wrote:
> 
> Well, as it was raised in this thread, ACPI tables are likely to be near RAM
> regions used for IPC with the firmware or SMBIOS, and we have no idea of the
> kind of crap that could happen if we enable caching on those areas.
> 

I'm really not sure I buy that argument -- at least not on x86: if that
is the case, then when PAT is off (and we fall down to MTRR-only
control) then we'd have the same failures.  If we mark them cacheable
and the MTRRs say uncachable, then we will *still* not cache them (since
MTRR UC overrides PAT WB -- in fact "PAT off" really just means ALL the
pagetables are marked WB.)

In that sense it is probably *safer* to map them WB, since the firmware
if it uses page tables at all is extremely likely to have all the cache
control bits at zero (meaning WB) -- and if it doesn't use page tables,
they are functionally zero by default (MTRR control only.)

So I think it'd be safer to map them cacheable -- regardless of if we
want to copy them to RAM or not.

	-hpa



  parent reply	other threads:[~2010-08-24 21:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-22 15:22 [RFC] - Mapping ACPI tables as CACHED Jack Steiner
2010-07-22 15:52 ` Len Brown
2010-07-23 16:38   ` Jack Steiner
2010-07-23  1:46 ` ykzhao
2010-07-23  7:23   ` Ingo Molnar
2010-07-23 14:26     ` ykzhao
2010-08-17 14:45       ` Jack Steiner
2010-08-17 15:51       ` H. Peter Anvin
2010-08-17 14:42     ` Jack Steiner
2010-08-17 14:39   ` Jack Steiner
2010-07-24  0:14 ` Henrique de Moraes Holschuh
2010-07-24  0:45   ` Matthew Garrett
2010-07-24 12:26     ` Henrique de Moraes Holschuh
2010-08-17 14:49   ` Jack Steiner
2010-08-17 16:02     ` Linus Torvalds
2010-08-17 16:02       ` Linus Torvalds
2010-08-24 21:39   ` H. Peter Anvin [this message]
2010-08-26 17:17     ` [RFC - V2] " Jack Steiner
2010-08-26 18:08       ` H. Peter Anvin
2010-12-08 21:22         ` Jack Steiner
2010-12-09  1:27           ` H. Peter Anvin
2010-12-09  3:50             ` Jack Steiner
2010-12-09  6:12               ` Len Brown
2010-08-17 15:59 ` [RFC] " Jack Steiner
2010-08-26 17:47   ` Len Brown

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=4C743C0F.2010101@zytor.com \
    --to=hpa@zytor.com \
    --cc=hmh@hmh.eng.br \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    /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.