All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "H. Peter Anvin" <hpa@linux.intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [RFC PATCH 3/3] x86, boot: Change the BIOS corruption checker to scan 640K
Date: Tue, 12 Nov 2013 10:42:10 +0100	[thread overview]
Message-ID: <20131112094210.GA11777@gmail.com> (raw)
In-Reply-To: <5281D682.4040700@linux.intel.com>


* H. Peter Anvin <hpa@linux.intel.com> wrote:

> On 11/11/2013 08:07 PM, Ingo Molnar wrote:
>
> > I agree with your patches so far, and I'd suggest we go even further: 
> > I'd say the config option is now a misnomer, it should probably be 
> > renamed to CONFIG_X86_FORCE_RESERVE_BIOS_LOW_1MB=y or so.
> 
> Why is that?  It doesn't seem to make much sense to me.  I think the 
> current option names seem to be just fine, but perhaps I'm missing 
> something.

My argument is that CONFIG_X86_CHECK_BIOS_CORRUPTION=y doesn't actually 
_check_ any 'BIOS corruption'. Its largest operative effect to the vast 
majority of users is to reserve the whole 1MB lower range to the BIOS and 
it performs no checking whatsoever.

That used to be different btw., it used to be on by default, that's why I 
named the option in such a way original. That original role has been 
almost completely eliminated though.

The _real_ option that turns on memory corruption checking is 
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y. (The 
memory_corruption_check=1 option is something very few users and 
essentially no distro will use - distros will use the .config option.)

> > Btw., should we also force-reserve the remaining bits over 640K..1MB, 
> > if they are not marked as reserved in the memory maps, or do we 
> > already force-reserve them somewhere?
> 
> We do, in trim_bios_range().  We treat it as available for I/O 
> assignments, since that is necessary on some systems.

Ok, good.

> > The CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y option and the 
> > memory_corruption_check=1 boot option then allow the activation of the 
> > low memory corrupion checker - which debug facility can be used on 
> > systems where someone wants to live dangerously and not reserve the 
> > low 1MB of RAM to the firmware.
> 
> That is indeed what this patch does, I think...

Yes, and that's my argument for simply renaming the option, no other 
change is needed IMO.

Thanks,

	Ingo

      reply	other threads:[~2013-11-12  9:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12  0:16 [RFC PATCH 0/3] x86, boot: Low memory reservation fixes H. Peter Anvin
2013-11-12  0:16 ` [RFC PATCH 1/3] x86, boot: Move setup_bios_corruption_check() later H. Peter Anvin
2013-11-12  0:16 ` [RFC PATCH 2/3] x86, boot: Change the default for X86_RESERVE_LOW to 640K, make EXPERT H. Peter Anvin
2013-11-12  0:16 ` [RFC PATCH 3/3] x86, boot: Change the BIOS corruption checker to scan 640K H. Peter Anvin
2013-11-12  4:07   ` Ingo Molnar
2013-11-12  7:19     ` H. Peter Anvin
2013-11-12  9:42       ` Ingo Molnar [this message]

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=20131112094210.GA11777@gmail.com \
    --to=mingo@kernel.org \
    --cc=hpa@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --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.