From: Mitch Bradley <wmb@firmworks.com>
To: Andres Salomon <dilinger@queued.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Yinghai Lu <yhlu.kernel@gmail.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Joseph Fannin <jfannin@gmail.com>,
linux-kernel@vger.kernel.org, jordan.crouse@amd.com
Subject: Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
Date: Sun, 20 Apr 2008 08:42:39 -1000 [thread overview]
Message-ID: <480B8E9F.8000701@firmworks.com> (raw)
In-Reply-To: <20080420135948.61bdb4c9@ephemeral>
Andres Salomon wrote:
> On Sun, 20 Apr 2008 08:07:55 -0400
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>
>
>> Yinghai Lu wrote:
>>
>>> On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon <dilinger@queued.net> wrote:
>>>
>>>> This adds 32-bit support for calling into OFW from the kernel. It's useful
>>>> for querying the firmware for misc hardware information, fetching the device
>>>> tree, etc.
>>>>
>>>> There's potentially no reason why other platforms couldn't use this, but
>>>> currently OLPC is the main user of it.
>>>>
>>>> This work was originally done by Mitch Bradley.
>>>>
>>>>
>> Hm. This interface seems more than a bit ad hoc. In particular, I
>> *really* don't like the swapper_pg_dir hack.
>>
>> "There must be a better way."
>>
>> -hpa
>>
>
> I'm certainly open to suggestions.. Otherwise, I'll poke around and
> see if I can come up w/ something.
>
The x86 architecture doesn't make this problem easy.
The conventional solution is to have the BIOS operate in real mode.
When the kernel calls into the BIOS, it has to do a grotesque dance that
involves jumping through a chain of several segments of different
flavors, thus gradually shutting down the multi-tiered address
translation mechanism. Then, if the BIOS is actually operating in
protected mode (which is necessary if it is larger than 64K, as all
modern BIOSes are), it has to perform the inverse process, do the
requested work, then go back into real mode to return to the kernel.
The net result is that a "call" into the BIOS involves:
a) Copying the arguments to a real-mode register shadow array
b) Saving all the registers - general ones and a few special ones too
c) Far call to a linear-mapped code segment with an execution address in
the first 1M of memory
d) Switching to a different stack
e) Turning off page translation
f) Switching from protected mode to real mode (or in some cases, V86
mode instead, which requires an additional Task State Segment dance to
set the IO permission mask)
g) Switching to a real-mode interrupt descriptor table
h) Executing an INT instruction
I) Performing the inverse of a - g inside the BIOS
j) Doing the requested work
K) Performing a - g again to get back into real mode
l) Executing an "iret" instruction
M) Performing the inverse of a-g to return to normal operation
The machinery that you need to do all that is predictably complex -
extra segment descriptors that are set up just-so, several little code
fragments that must be at special addresses in the first meg, additional
stacks, a real-mode interrupt table at a fixed address, and several data
save arrays. That machinery has to be in assembly language, spanning
several different instruction set modes.
Compared to that, I think that sharing one or two page directory entries
at the very top of the virtual address space is pretty clean and
simple. With that sharing, the BIOS call is just an ordinary subroutine
call. (The setup code copies the entire page directory, but only a
couple of entries are actually needed. The reason for copying the whole
thing is because it is rather more work to determine the exact number of
entries necessary, compared to copying everything and then letting Linux
replace the ones it uses.)
Every other solution that I know of requires some sort of heroic dance,
either from the OS or from the BIOS or (usually) both.
next prev parent reply other threads:[~2008-04-20 18:52 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
2008-04-18 11:26 ` [PATCH] 2.6.25-mm1 - Build Failure with PWRficient onchip memory controller driver Kamalesh Babulal
2008-04-18 13:02 ` StackProtector Oopses - Re: 2.6.25-mm1 Reuben Farrelly
2008-04-18 13:36 ` Ingo Molnar
2008-04-18 13:51 ` Arjan van de Ven
2008-04-18 14:41 ` Reuben Farrelly
2008-04-18 14:49 ` Reuben Farrelly
2008-04-21 15:06 ` Ingo Molnar
2008-04-22 1:48 ` Arjan van de Ven
2008-04-22 2:04 ` Valdis.Kletnieks
2008-04-22 8:34 ` Ingo Molnar
2008-04-22 14:29 ` Arjan van de Ven
2008-04-18 16:40 ` 2.6.25-mm1 (build error: driver core) Randy Dunlap
2008-04-18 16:56 ` Greg KH
2008-04-18 18:38 ` Dan Williams
2008-04-18 16:45 ` 2.6.25-mm1 (build error: trace selftest) Randy Dunlap
2008-04-18 20:14 ` 2.6.25-mm1 Valdis.Kletnieks
2008-04-18 23:09 ` 2.6.25-mm1: orphaned files after build Alexey Dobriyan
2008-04-19 2:13 ` 2.6.25-mm1 Joseph Fannin
2008-04-19 3:02 ` 2.6.25-mm1 Andrew Morton
2008-04-19 4:14 ` 2.6.25-mm1 Dmitry Torokhov
2008-04-19 4:29 ` 2.6.25-mm1 Andrew Morton
2008-04-19 6:33 ` 2.6.25-mm1 Joseph Fannin
2008-04-21 11:07 ` 2.6.25-mm1 Takashi Iwai
2008-04-21 17:44 ` 2.6.25-mm1 (snd-pcsp causes driver conflict) Stas Sergeev
2008-04-22 10:09 ` Takashi Iwai
2008-04-22 17:54 ` Stas Sergeev
2008-04-23 8:55 ` Takashi Iwai
2008-04-23 14:14 ` Takashi Iwai
2008-04-21 19:45 ` 2.6.25-mm1 Stas Sergeev
2008-04-21 14:06 ` 2.6.25-mm1 Takashi Iwai
2008-04-21 17:55 ` 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC) Stas Sergeev
2008-04-22 10:13 ` Takashi Iwai
2008-04-22 14:01 ` Dmitry Torokhov
2008-04-22 16:42 ` Stas Sergeev
2008-04-22 18:31 ` Stas Sergeev
2008-04-23 8:49 ` Takashi Iwai
2008-04-23 14:18 ` Takashi Iwai
2008-04-23 20:02 ` Stas Sergeev
2008-04-24 9:40 ` Takashi Iwai
2008-04-25 3:51 ` Stas Sergeev
2008-04-25 6:28 ` Takashi Iwai
2008-04-25 16:45 ` Stas Sergeev
2008-04-25 16:51 ` Takashi Iwai
2008-04-25 17:25 ` Stas Sergeev
2008-05-02 16:44 ` Takashi Iwai
2008-05-02 16:57 ` Stas Sergeev
2008-05-06 10:20 ` Takashi Iwai
2008-05-06 16:51 ` Stas Sergeev
2008-04-25 18:09 ` Dmitry Torokhov
2008-04-25 18:31 ` Stas Sergeev
2008-04-25 18:37 ` Dmitry Torokhov
2008-04-19 2:25 ` 2.6.25-mm1 Joseph Fannin
2008-04-19 3:08 ` 2.6.25-mm1 Andrew Morton
2008-04-19 3:10 ` 2.6.25-mm1 Joseph Fannin
2008-04-19 3:29 ` 2.6.25-mm1 Andrew Morton
2008-04-19 13:25 ` 2.6.25-mm1 Andres Salomon
2008-04-19 17:38 ` 2.6.25-mm1 Andrew Morton
2008-04-19 17:50 ` 2.6.25-mm1 Andres Salomon
2008-04-21 14:56 ` 2.6.25-mm1 Jordan Crouse
2008-04-21 15:05 ` 2.6.25-mm1 Andres Salomon
2008-04-21 15:12 ` 2.6.25-mm1 Jordan Crouse
2008-04-19 17:39 ` [PATCH 1/2] OLPC: Add support for calling into Open Firmware Andres Salomon
2008-04-20 10:34 ` Yinghai Lu
2008-04-20 12:07 ` H. Peter Anvin
2008-04-20 17:59 ` Andres Salomon
2008-04-20 18:42 ` Mitch Bradley [this message]
2008-04-20 19:12 ` H. Peter Anvin
2008-04-21 3:39 ` Mitch Bradley
2008-04-21 4:54 ` Yinghai Lu
2008-04-21 8:22 ` Mitch Bradley
2008-04-21 11:36 ` H. Peter Anvin
2008-04-21 13:09 ` H. Peter Anvin
2008-04-21 13:13 ` H. Peter Anvin
2008-04-21 13:19 ` H. Peter Anvin
2008-04-21 15:05 ` Jordan Crouse
2008-04-21 14:58 ` H. Peter Anvin
2008-04-20 19:13 ` [PATCH 1/2] " H. Peter Anvin
2008-04-21 3:09 ` Mitch Bradley
2008-04-21 3:15 ` Yinghai Lu
2008-04-21 4:05 ` Mitch Bradley
2008-04-21 4:26 ` David Miller
2008-04-21 4:50 ` Yinghai Lu
2008-04-21 8:03 ` Mitch Bradley
2008-04-21 14:24 ` Andres Salomon
2008-04-21 15:54 ` David Woodhouse
2008-04-21 16:57 ` H. Peter Anvin
2008-04-21 18:54 ` David Woodhouse
2008-04-21 17:03 ` Andres Salomon
2008-04-21 19:18 ` David Woodhouse
2008-04-21 19:46 ` Andres Salomon
2008-04-21 20:25 ` David Woodhouse
2008-04-21 21:02 ` [PATCH] OLPC: only check for OFW signature on VSA-less Geodes Andres Salomon
2008-04-21 21:17 ` Jordan Crouse
2008-04-21 21:17 ` [PATCH] " David Woodhouse
2008-04-29 3:06 ` Andrew Morton
2008-04-29 5:32 ` [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline Andres Salomon
2008-04-29 20:35 ` Andrew Morton
2008-04-29 20:57 ` Andres Salomon
2008-04-19 17:39 ` [PATCH 2/2] OLPC: drop pre-OpenFirmware workarounds Andres Salomon
2008-04-19 18:21 ` 2.6.25-mm1 Arjan van de Ven
2008-04-20 11:29 ` internal compiler error: SIGSEGV [Was: 2.6.25-mm1] Jiri Slaby
2008-04-21 8:31 ` Jiri Slaby
2008-04-21 9:06 ` Al Viro
2008-04-21 9:37 ` fault in __d_lookup " Jiri Slaby
2008-04-21 9:45 ` Al Viro
2008-04-21 9:59 ` Jiri Slaby
2008-04-21 13:42 ` Rafael J. Wysocki
2008-04-21 17:23 ` Matthew Wilcox
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=480B8E9F.8000701@firmworks.com \
--to=wmb@firmworks.com \
--cc=akpm@linux-foundation.org \
--cc=dilinger@queued.net \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jfannin@gmail.com \
--cc=jordan.crouse@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=yhlu.kernel@gmail.com \
/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