[Skiboot] [RFC PATCH] Virtual Memory for OPAL boot
npiggin at gmail.com
Thu Apr 30 09:33:46 AEST 2020
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
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
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.
More information about the Skiboot