From: "H. Peter Anvin" <hpa@zytor.com>
To: Matthew Garrett <mjg@redhat.com>
Cc: Randy Wright <rwright@hp.com>,
linux-kernel@vger.kernel.org,
Thavatchai Makphaibulchoke <tmac@hp.com>
Subject: Re: [PATCH RFC] function probe_roms accessing improper addresses
Date: Fri, 19 Oct 2012 08:37:58 -0700 [thread overview]
Message-ID: <508173D6.6040209@zytor.com> (raw)
In-Reply-To: <20121019153015.GD28212@srcf.ucam.org>
On 10/19/2012 08:30 AM, Matthew Garrett wrote:
> I don't think DMI checking is going to work, since (a) as you say,
> there's a risk that the ID will inadvertantly change over the lifecycle
> of the machine, and (b) there may be other machines. So if it's not
> possible to handle this by catching the MCE, I think we have two
> options:
>
> 1) Declare that any x86 hardware supported by Linux *must* support
> probing in this address region
>
> 2) Don't call probe_roms() by default, but leave it up to the graphics
> drivers. If they can get the rom by any other means then don't call it.
>
Honestly, (1) is the proper option. Hearing that this is a prototype, I
would like to say "fix your bloody hardware/firmware"...
The legacy region is special and will always be special, and so any
attempts at making it non-special is a losing battle.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2012-10-19 15:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <jQZho-4fF-13@gated-at.bofh.it>
[not found] ` <jSWfn-7B6-3@gated-at.bofh.it>
2012-10-19 15:20 ` [PATCH RFC] function probe_roms accessing improper addresses Randy Wright
2012-10-19 15:30 ` Matthew Garrett
2012-10-19 15:37 ` H. Peter Anvin [this message]
2012-10-23 16:05 ` Randy Wright
2012-10-23 16:27 ` Matthew Garrett
2012-10-04 19:22 [PATCH RFC] function probe_roms accessing improper addresses on UEFI systems Matthew Garrett
2012-10-10 4:31 ` [PATCH RFC] function probe_roms accessing improper addresses Randy Wright
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=508173D6.6040209@zytor.com \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=rwright@hp.com \
--cc=tmac@hp.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 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.