[Skiboot] [RFC PATCH] Virtual Memory for OPAL boot

[Nicholas Piggin]

Excerpts from Cédric Le Goater's message of April 29, 2020 7:49 pm:
> On 4/28/20 9:44 AM, Nicholas Piggin wrote:
>> vm_map_global / vm_unmap_global sets up all-CPUs visible 1:1 mappings.
>> vm_map / vm_unmap creates a per-cpu mapping, and which can not be nested.
>> 
>> A list of global extents + a local extent per cpu is kept to describe
>> active mappings. Fault handlers look these up to install translations.
>> 
>> Booting with virtual memory is all well and good, and it can help find
>> bugs. The bigger benefit is that a logical virtual map is created in
>> the process, which can be given to the OS and used to create a virtual> memory environment for the OPAL runtime to execute in.
> 
> The goal is to turn OPAL into a kernel driver and the OPAL calls into 
> simple function calls ?  

Yes. Kind of.

Not so close coupled to the kernel for practical matters, but I would 
like skiboot to be able to use a few of the most useful facilities of 
the kernel.

printk, trap/bug/symbol printing is obvious and easy. Virtual memory is
important for security and also keeping firmware safe(r) from kernel and 
vice versa, and we want to get rid of real-mode after boot as far as 
possible.

I'll post the skiboot and Linux patches to do these again soon.

There are other features we can provide to skiboot which sound good but 
we should be very careful to add them, and only if there is real benefit 
that outweighs complexity. ftrace, sleep/wake/timer, perf interrupts, 
maybe a tunables that can be exported in a sysfs directory. I don't 
know, lots of ideas but start very small and careful.

The opposite way to go about this is have the firmware provide code 
(e.g., bytecode like AML or eBPF) and then have the kernel execute that 
in kernel context. I kind of considered that but it seems backwards and 
pointless when we have open source firmware, we can do it this way and 
mostly keep the same APIs etc.

Thanks,
Nick