[coreboot] About Paging, Realmode and what is going on

[Zoran Stojsavljevic]

OK Ron,

I needed some time to reconcile my thoughts. So,as Aaron pointed, it is
impossible to do any long mode paging in ROM stage.

And here we come to the Mystery of CB Organism (hmmmm... It is very close
to some other term). ;-)

Now, here is how it will play for you and Coreboot, after ROM stage (I'll
call it RON stage, since it is RAM stage, divided in two sections).

Why RON? Ready Or Not, that is the question!

So RON stage = RAM1 stage + RAM2 stage.

RAM1 stage: Since some RAM Physical mapping (AFTER CRB) MUST be done at the
beginning of the RAM stage, lookalike BIOS one (in PEI phase, I assume), CB
will proceed with the usual activities, set in Protected Mode. And, as we
know so far how it works, it'll finish this phase, looking for Payload.

Now, instead of payload stage, here we go with the RAM2 stage. Now the CB
will switch to the Long Mode (flat x86_64), addressing at maximum of 48
bits of the physically available CPU address memory bus - 256 TB of DDRAM
memory (I'll drop here 64 bit PAE extension (additional 4 bits of physical
address space), for clarity).

Here, you'll start initializing MMU, with 4 TLB tables: CR3 -> PML4 (512
entries) -> PDTP (512 entries) -> PDT (512 entries) -> PT (512 entries +
last 12 bits freed for the MMU attributes). So, if your HW have in average
8GB of memory, you'll need ONLY 1 entry in PML4, 8 entries in PDTP -> and
full tables for these 8 entries. I see that you'll do NOT a Virtualization,
rather a logical address shift for the constant address offset. With proper
init of the attributes in the PE tables, per 4KB page - your finest
granularity).

And, YES, you'll have your memory protection in full swing (just for the
de-referencing the NULL pointers), since you do NOT have more that one
process working, in linear mode (so the bus error will appear ONLY for NULL
pointers).

Now, after you've done this, what is the next step, somebody will ask?
[A] Reverting to Protected Mode prior Payload stage?
[B] Proceeding with the Long Mode passing thread of execution to
payloads... Which need to operate in Long Mode!? Really???
[C] Reverting to Virtual x86 Mode???
[D] Reverting to Real Mode???

Seems that you will do scenario [A]. But if you choose to have payload as
64b Linux [B], then I see where you are pointing/going with this
approach... To fast Server (?!) boot-ups, but you need to reconsider, since
64b Linux still will reconfigure MMU, doesn't it???

Or you would like to skip kernel MMU init while booting 64b kernel. Letting
kernel to pick up (already) hot MMU, on fly?

As far, it'll be: Boot stage + ROM stage + RON stage (RAM1 stage in
Protected Mode, + RAM2 stage in 64b Long Mode) + 64b kernel payload. Solely
out of FLASH (smells as DOD MIL RT applications, drones, unmanned planes,
missiles)... Interesting scenario, anyway!

(Mysteries of CB organisms) ;-)

Zoran

On Wed, Aug 2, 2017 at 9:45 PM, ron minnich <rminnich at gmail.com> wrote:

> right, Aaron, you keep reminding me of that and I keep forgetting it :-)
>
> so, ok, ramstage it is for paging. The x86 is so darned annoying. We had
> paging in the bootblock for PPC on linuxbios.
>
> On Wed, Aug 2, 2017 at 12:43 PM Aaron Durbin <adurbin at google.com> wrote:
>
>> On Wed, Aug 2, 2017 at 1:36 PM, ron minnich <rminnich at gmail.com> wrote:
>> >
>> >
>> > On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic
>> > <zoran.stojsavljevic at gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> So, turning on the Virtual Mode (paging ON), you'll also imply that
>> >> Coreboot will initialize and use MMU, don't you?
>> >
>> >
>> > sure.
>> >
>> >>
>> >>
>> >> Am I correct, or you can use paging without MMU?!
>> >
>> >
>> > MMU must be on.
>> >
>> >>
>> >> I doubt that, perhaps. So, then, I would like to see this code in
>> Coreboot
>> >> where MMU is initialized. And how it is initialized (maybe there is a
>> some
>> >> over-simplified mode of operation using 2MB pages).
>> >
>> >
>> > yep.
>> >
>> >>
>> >>
>> >> And my question is: what for? Or I did not get the idea... Who really
>> >> needs to use paging in boot-loaders? Even INTEL, which (on purpose)
>> makes
>> >> things way over-dimensioned and over-complicated, does NOT use paging
>> in
>> >> UEFI BIOSes, so far???
>> >>
>> >
>> > it's trivial to turn on paging. In harvey I've got it down to 160 lines,
>> > including comments and white space. I made it much more compact in my CL
>> > from 1/2014.
>> >
>> > If you turn on paging you can capture null pointer derefs, and all
>> other out
>> > of range address references. And relocatable modules are much easier..
>> >
>> > My question is, why not do it? I don't see any harm. All the other
>> platforms
>> > in coreboot use paging. What's so special about x86 that it should not
>> use
>> > paging?
>>
>> You can't use it for CAR so that sorta throws out romstage and before.
>> It's up to the implementation of how CAR works within the hierarchy,
>> but with hardware page walkers that pull things through the cache
>> things can go badly. So then you could enable paging for ramstage.
>> Need to locate storage for the page tables, but that's not an
>> impossible thing either.
>>
>> >
>> > ron
>> >
>> > --
>> > coreboot mailing list: coreboot at coreboot.org
>> > https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170803/a5cf5973/attachment.html>