From: Matt Fleming <matt.fleming@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
cJ-ko@zougloub.eu, "H. PeterAnvin" <hpa@zytor.com>
Subject: Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting
Date: Thu, 09 Aug 2012 09:51:35 +0100 [thread overview]
Message-ID: <1344502295.9195.7.camel@mfleming-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <50210F0702000078000932EB@nat28.tlf.novell.com>
On Tue, 2012-08-07 at 11:50 +0100, Jan Beulich wrote:
> >
> > I managed to find a machine to reproduce this on and it looks like the
> > ASUS firmware engineers are upto their old tricks of referencing
> > physical addresses after we've taken control of the memory map,
>
> Yippie. On such systems we simply can't do any runtime calls.
> Should we add a command line option forcing efi_native to false,
> thus suppressing all runtime calls? Or would the "noefi" one be
> enough already?
I think a better solution for this, seeing as there appear to be *so*
many ASUS machines in the wild with this inability to do virtual EFI
calls, is to provide a 1:1 mapping as well as our regular virt->phys
mapping for the benefit of the firmware. We can load our special page
table in efi_call_*, etc.
One thing to note is that because of breakage seen on Apple machines
last time Matthew tried this approach, we (the kernel) can't actually
access the 1:1 mapping, it would exist purely for the benefit of
firmware that was broken enough to reference physical addresses after
SetVirtualAddressMap().
next prev parent reply other threads:[~2012-08-09 8:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-05 21:29 [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting Jérôme Carretero
2012-08-05 22:28 ` H. Peter Anvin
2012-08-06 6:44 ` Jan Beulich
2012-08-06 12:52 ` Matthew Garrett
2012-08-06 13:08 ` Jan Beulich
2012-08-06 13:16 ` Jérôme Carretero
2012-08-06 13:25 ` Jan Beulich
2012-08-06 23:29 ` Jérôme Carretero
2012-08-07 7:05 ` Jan Beulich
2012-08-07 2:32 ` Jérôme Carretero
2012-08-07 3:06 ` Jérôme Carretero
2012-08-07 7:14 ` Jan Beulich
2012-08-07 9:30 ` Matt Fleming
2012-08-07 10:50 ` Jan Beulich
2012-08-09 8:51 ` Matt Fleming [this message]
2012-08-10 19:22 ` Yinghai Lu
2012-08-10 19:26 ` Matthew Garrett
2012-08-21 14:16 ` Matt Fleming
2012-08-10 3:49 ` Jérôme Carretero
2012-08-14 19:43 ` [tip:x86/urgent] Revert "x86-64/efi: Use EFI to deal with platform wall clock" tip-bot for 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=1344502295.9195.7.camel@mfleming-mobl1.ger.corp.intel.com \
--to=matt.fleming@intel.com \
--cc=JBeulich@suse.com \
--cc=cJ-ko@zougloub.eu \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mjg59@srcf.ucam.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.