linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@linux.intel.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Robin Holt <holt@sgi.com>,
	linux-kernel@vger.kernel.org, "Sakkinen,
	Jarkko" <jarkko.sakkinen@intel.com>
Subject: Re: [PATCH] phys_efi_set_virtual_address_map needs va, no pa.
Date: Wed, 20 Jun 2012 13:41:54 -0700	[thread overview]
Message-ID: <4FE23592.60201@linux.intel.com> (raw)
In-Reply-To: <20120620120702.GA3983@srcf.ucam.org>

On 06/20/2012 05:07 AM, Matthew Garrett wrote:
> 
> No, that's completely wrong. UEFI can't be called in virtual mode until 
> *after* SetVirtualAddressMap(). The UEFI spec indicates that all 
> physical memory must have an identity mapping at this stage (section 
> 2.3.4), so if we don't then that's a bug that needs to be fixed.
> 

I think it is a bug, and with the trampoline work in 3.4 we should
finally have a proper platform to fix it.

In particular, we should keep a full 1:1 page map around, and it should
be the one that is in the trampoline (real_mode_header->trampoline_pgd)
as we need the page directory to be 32-bit addressable.

The right thing to do is to sync the pgds in the 1:1 area, both for 64
bit and for legacy 32 bit (PAE 32 bit don't need it, since all the
kernel maps are shared.)  This is currently done ad hoc (and
differently!) on both 32 and 64 bits and that really should be fixed.

Once that is properly fixed, we have a usable identity mapping.

On that subject, I have been thinking about the kexec use case.  I'm
thinking that if we indeed cannot use either physical mode nor a
zero-offset virtual mode, that the most likely sane thing to do is to
use a fixed offset of 2^46 and still use a (pseudo-)1:1 map.

Do we have any data at all on machines that supposedly can't use
identity-mapped EFI?

	-hpa

  reply	other threads:[~2012-06-20 20:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-20  8:24 [PATCH] phys_efi_set_virtual_address_map needs va, no pa Robin Holt
2012-06-20 12:07 ` Matthew Garrett
2012-06-20 20:41   ` H. Peter Anvin [this message]
2012-06-21  0:27     ` Robin Holt
2012-06-21  0:46       ` H. Peter Anvin
2012-06-21 16:52         ` Robin Holt
2012-06-22  0:35           ` H. Peter Anvin
2012-06-21 19:16         ` Konrad Rzeszutek Wilk

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=4FE23592.60201@linux.intel.com \
    --to=hpa@linux.intel.com \
    --cc=holt@sgi.com \
    --cc=jarkko.sakkinen@intel.com \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).