From: Alex Thorlton <athorlton@sgi.com>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Alex Thorlton <athorlton@sgi.com>,
linux-kernel@vger.kernel.org, Borislav Petkov <bp@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Mike Travis <travis@sgi.com>, Russ Anderson <rja@sgi.com>,
Dimitri Sivanich <sivanich@sgi.com>,
x86@kernel.org, linux-efi@vger.kernel.org
Subject: Re: [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic
Date: Thu, 2 Jun 2016 16:14:03 -0500 [thread overview]
Message-ID: <20160602211403.GD242721@stormcage.americas.sgi.com> (raw)
In-Reply-To: <20160602194547.GK2658@codeblueprint.co.uk>
On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote:
> Unless I've missed it, I didn't see an explanation in the changelog of
> why it's OK to switch from using __va(tab->function) to tab->function
> directly, which presumably is a physical address.
>
> Was that intended?
It was intended. The motivation is so that we can use the same
"dereference the pointer inside the macro" stuff that we do with the
efi.systab->runtime pointer. IINM, the reason it works is because we do
/*
* Make sure the 1:1 mappings are present as a catch-all for b0rked
* firmware which doesn't update all internal pointers after switching
* to virtual mode and would otherwise crap on us.
*/
__map_region(md, md->phys_addr);
Inside of efi_map_region, so we know we'll have that physical address
mapped into the EFI page table.
Upon review, I'm wondering if the correct thing to do here is to
update that pointer during the switch to virtual mode, to avoid the
b0rkage mentioned in the above comment.
Either way, the straigh tab->function dereference should work while
using the EFI page table, but I do wonder if that tab->function address
should have been updated to the __va() version of itself before we reach
this point.
Maybe you can comment on that?
- Alex
next prev parent reply other threads:[~2016-06-02 21:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-18 19:11 [RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use Alex Thorlton
2016-05-18 19:11 ` [PATCH 1/3] Convert efi_call_virt to efi_call_virt_generic Alex Thorlton
2016-06-02 15:41 ` Matt Fleming
2016-06-02 16:23 ` Alex Thorlton
2016-05-18 19:11 ` [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic Alex Thorlton
2016-06-02 19:45 ` Matt Fleming
2016-06-02 21:14 ` Alex Thorlton [this message]
2016-06-02 21:56 ` Alex Thorlton
2016-05-18 19:11 ` [PATCH 3/3] Update efi_thunk " Alex Thorlton
2016-06-02 20:19 ` Matt Fleming
2016-06-02 21:25 ` Alex Thorlton
2016-05-18 19:13 ` [RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use Alex Thorlton
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=20160602211403.GD242721@stormcage.americas.sgi.com \
--to=athorlton@sgi.com \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@redhat.com \
--cc=rja@sgi.com \
--cc=sivanich@sgi.com \
--cc=tglx@linutronix.de \
--cc=travis@sgi.com \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®