From: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@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, 30 Apr 2013 17:23:29 +0100 [thread overview]
Message-ID: <20130430162329.GA7962@srcf.ucam.org> (raw)
In-Reply-To: <517FE891.9070103-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Tue, Apr 30, 2013 at 10:51:45AM -0500, Joel Schopp wrote:
> On 04/30/2013 07:52 AM, Matthew Garrett wrote:
> >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. 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.
> >
> >Sigh. Is the spec final yet? Doing this in ACPI is inconvenient - ACPI
> >isn't available at the stage where we do early UEFI setup, so it would
> >have been much easier if this had been a UEFI table rather than an ACPI
> >one.
>
> The spec appears to currently be in purgatory, finished but not
> published. Do you happen to know offhand what spec defines the UEFI
> runtime services table?
That's in the UEFI spec, but it wouldn't be appropriate to put it there.
Instead, you can add another UEFI table with a different UUID and have a
pointer to that from the ConfigurationTables pointer in the UEFI system
table.
> >
> >>2) Various methods to map in the physical address into virtual
> >>address space and then call the virtual address. All of these have
> >>failed.
>
> Turns out there was a bug in the UEFI implementation, I'm pretty
> sure we have a way to map it in and call it now.
Cool.
--
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
prev parent reply other threads:[~2013-04-30 16:23 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
[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 [this message]
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=20130430162329.GA7962@srcf.ucam.org \
--to=mjg59-1xo5oi07kqx4cg9nei1l7q@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.