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

[ron minnich]

in the akaros virtual machine code, we set up a simple 1:1 map and start
linux at the 64-bit entry point, at which point it builds its own page
tables. So entering a payload in long mode is certainly possible and IMHO
ought to be the standard on amd64 -- not that anyone cares what I think
anyway :-)

Anyway, I'm going to be working on replacing ramstage with linux again, so
I'm not as concerted with coreboot ramstage just now ;-)

On Thu, Aug 3, 2017 at 9:16 AM Zoran Stojsavljevic <
zoran.stojsavljevic at gmail.com> wrote:

> 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/20170805/4e4c8be3/attachment.html>