All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
To: Joel Schopp <jschopp-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Leonidas da Silva Barbosa
	<leosilva-xuelUoVDAHHQT0dZR+AlfA@public.gmane.org>
Subject: Re: unusual uefi call/mapping problem
Date: Tue, 16 Apr 2013 19:40:56 -0700	[thread overview]
Message-ID: <20130417024056.GA13609@kroah.com> (raw)
In-Reply-To: <516DC325.6090604-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

On Tue, Apr 16, 2013 at 04:31:17PM -0500, Joel Schopp wrote:
> I'm working on the Linux kernel implementation of an draft standard
> that has a uefi component.

What standard would that be?

> The interesting part is that the uefi
> component isn't in the uefi runtime table, but instead has a
> physical address stored an ACPI table.  Other than not being in the
> runtime table it behaves exactly like the other runtime services.
> 
> After extracting the physical address of the UEFI service we can't
> successfully map it or call it.

You want to call it from the kernel?  Why?  Usually you get a "virtual"
address to call UEFI things, and then use efi_call_virt?(), why can't
you do that here as well?

> I'm sure this is straightforward to
> somebody with experience in this area.  Here's a few of the things
> I've tried unsuccessfully, any pointers here would be appreciated.
> 
> 1) Call the physical address
> efi_call_phys_prelog();
> efi_call_phys5(...);
> efi_call_phys_epilog();
> 
> This generates some nasty scheduling while atomic errors

As it should :)

> 2) Various methods to map in the physical address into virtual
> address space and then call the virtual address.  All of these have
> failed.

Why?  What have you done that failed?  Any pointers to code anywhere?

Are you trying to do this before we switch to virtual mode, or after?

thanks,

greg k-h

  parent reply	other threads:[~2013-04-17  2:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16 21:31 unusual uefi call/mapping problem Joel Schopp
     [not found] ` <516DC325.6090604-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2013-04-17  2:40   ` Greg KH [this message]
     [not found]     ` <20130417024056.GA13609-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2013-04-17  5:04       ` Joel Schopp
2013-04-30 12:52   ` Matthew Garrett
     [not found]     ` <20130430125225.GA4197-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
2013-04-30 15:51       ` Joel Schopp
     [not found]         ` <517FE891.9070103-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2013-04-30 16:23           ` Matthew Garrett

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=20130417024056.GA13609@kroah.com \
    --to=gregkh-hqyy1w1ycw8ekmwlsbkhg0b+6bgklq7r@public.gmane.org \
    --cc=jschopp-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    --cc=leosilva-xuelUoVDAHHQT0dZR+AlfA@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.