All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Herrmann <herrmann.der.user@googlemail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Jacob Shin <jacob.shin@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH 1/1] x86, e820: Remove direct mapping of reserved space for HT hole around 1TB
Date: Thu, 13 Oct 2011 11:57:34 +0200	[thread overview]
Message-ID: <20111013095734.GA16748@alberich.amd.com> (raw)
In-Reply-To: <4E94D4E7.5010001@zytor.com>

On Tue, Oct 11, 2011 at 04:44:39PM -0700, H. Peter Anvin wrote:
> On 10/11/2011 03:09 PM, Jacob Shin wrote:
> > The entire HT hole and also the unused address range before that hole
> > need to be excluded from direct mapping. Otherwise speculative
> > accesses to that reserved region can happen which cause machine
> > checks.

> BARF!

> This is completely insane ad hockery when all that really should
> need to happen is marking the HT region RESERVED, which should be
> possible on any HT-equipped processor.

Great, thanks for this hint, I would never have thought that ...  but
wait, guess what, we have tried this already.

Initially we had following situation:

  BIOS-e820: 0000000100000000 - 000000e038000000 (usable)
  BIOS-e820: 000000e038000000 - 000000fd00000000 (reserved)
  BIOS-e820: 0000010000000000 - 0000011fff000000 (usable)
 ...
 init_memory_mapping: 0000000100000000-0000011fff000000
  0100000000 - 11fc0000000 page 1G
  11fc0000000 - 11fff000000 page 2M
 kernel direct mapping tables up to 11fff000000 @ 11ffeffc000-11fff000000

But MCEs due to speculative accesses happened to the reserved region
before the HT hole.

So what is the point in including address space below TOM2 not backed
with memory in kernel's direct mapping? For similar reserved space
before 4GB we don't do this.

Instead of barfing, some more constructive feedback would be
appreciated.


Thanks,

Andreas

  reply	other threads:[~2011-10-13  9:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-11 22:09 [PATCH 1/1] x86, e820: Remove direct mapping of reserved space for HT hole around 1TB Jacob Shin
2011-10-11 23:44 ` H. Peter Anvin
2011-10-13  9:57   ` Andreas Herrmann [this message]
2011-10-13 15:52     ` H. Peter Anvin
2011-10-13 11:04 ` Andreas Herrmann
2011-10-14  5:45   ` Yinghai Lu
2012-10-16 16:47 ` Shuah Khan
     [not found] <6ec48b96-afab-4c8b-ab74-2c640c2a161b@blur>
     [not found] ` <8630fe28-0c1c-4f3a-90e1-df2d1b6615a6@blur>
2012-10-16 17:48   ` Shuah Khan
2012-10-16 18:26     ` Jacob Shin
2012-10-16 19:02       ` H. Peter Anvin
2012-10-17 15:30         ` Shuah Khan
2012-10-17 18:25       ` 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=20111013095734.GA16748@alberich.amd.com \
    --to=herrmann.der.user@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=jacob.shin@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.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 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.