GSoc-2017: Platforms - Microkernelizing Linux, help needed

Wed Mar 1 16:58:41 CET 2017

Hi Norman,

Thanks for the detailed suggestions with so much patience. I'm a
practitioner, so I really appreciate details, and I'll check out the stuff
that you've mentioned and try to get started ASAP.

BTW, do you have any suggestions on small related tasks that I can take in
prior to my formal application for the GSoC project? I think committing
small patches would be a great starting point to getting familiar with the
Genode codebase.

Best Regards,

Zhongze Liu.

2017-03-01 19:37 GMT+08:00 Norman Feske <norman.feske at ...1...>:

> Hello Sky Liu,
>
> thank you for your interest in Genode!
>
> > I'm a college student majoring Information Security in HUST, and I'm
> > interested in genode's GSoC project on microkernelizaing the Linux
> > kernel. I've been quite interested in microkernel OSs and
> > virtualization, with limited experiences working on xen and the linux
> > kernel. and have been in the MINIX community for a short time, so I was
> > attracted by this challenge at the first sight.
> >
> > However, I'm still new to the genode project. So I'll appreciate it if I
> > could get from you some suggestions on where to get started. :)
>
> The best way to start exploring Genode is the "Genode Foundations" book,
> which you can download here:
>
>   http://genode.org/documentation/genode-foundations-16-05.pdf
>
> I recommend you to at follow the getting-started section, and skim over
> the Chapter 3 (Architecture) and Section 4.7 (Component compositions) to
> get a tangible feeling for Genode.
>
> To practically tackle the "microkernelization of Linux", there are
> actually two approaches. (1) The first approach is to enable Genode to
> access devices of the Linux system you are working on. This is
> convenient, but it bears the risk that a device driver (running in a
> Genode component) may interfere with the Linux kernel, crashing the
> system. The other approach (2) is booting a custom-made Linux system +
> Genode's core as init process in Qemu. The latter approach would be
> equivalent to how we work with the various microkernels.
>
> Depending on your interests, you may quickly dive in into the actual
> Genode code (1) or work on a custom run environment for Linux-based
> Genode system (2) first.
>
> Regarding the actual topic, the overall challenge is allowing Genode's
> device drivers access to the hardware that is normally accessed by the
> Linux kernel only. From Linux' point of view, Genode appears as a
> user-level device driver. So one piece of the puzzle is to gain a good
> understanding of Linux' user-level device-driver support. From Genode's
> perspective, device hardware is accessed through the IO_MEM, IO_PORT,
> and IRQ services of Genode's core component. So in principle, the topic
> comes down to implementing these services for the 'base-linux' version
> of core by using Linux' interfaces for user-level device drivers.
>
> There are several stages:
>
> 1. By implementing the IO_PORT service, Genode components can interact
>    with simple port-I/O-devices such as the PIT timer. The
>    implementation should by straight-forward: When running core at
>    I/O privilege level (IOPL) 3, core can execute the regular
>    'inb', 'outb', etc. instructions. A simple test component could
>    request a Genode IO_PORT session for, let's say, the PIT, program
>    the PIT as a running counter, and repeatedly read the current
>    counter value.
>
> 2. Non-trivial devices need access to memory-mapped I/O registers.
>    Core's IO_MEM service makes such registers available to its
>    clients as a dataspace (the concept is explained in the book).
>    On Linux, dataspaces are represented as memory-mapped files, passed
>    from core to the driver component by passing a file descriptor, and
>    attached to the driver's address space via 'mmap'. Consequently,
>    the problem comes down to core obtaining a file descriptor for
>    a given physical address region. Here the challenge is to find
>    a suitable Linux kernel mechanism that hands out portions of
>    physical memory as a file descriptor.
>
>    With the principle support for memory-mapped I/O and port I/O
>    in place, it should be possible to run the VESA framebuffer driver.
>
> 3. Most drivers use device interrupts. To use those drivers, core's
>    IRQ service needs to be implemented. Again, this calls for an
>    investigation of Linux' user-level device driver support.
>
> 4. Direct memory access. Many drivers use DMA to let the device
>    write directly into memory. For this to work, the driver must
>    supply the targeted memory address to the device. On systems
>    without IOMMU, this is the physical bus address. In order to
>    use DMA on Genode/Linux, DMA buffers need to be allocated as
>    contiguous physical memory and their physical addresses must
>    become known to the user-level driver component. In systems with
>    IOMMU, the device-physical addresses a virtualized. So there is
>    more freedom. But the details ultimately depends on the Linux
>    handling of IOMMUs.
>
> 5. In Genode, PCI devices are managed by the so-called platform
>    driver. When a regular device driver needs access to a certain
>    device, it does not use core's IO_MEM, IO_PORT, and IRQ services
>    directly but it requests a platform session. A platform session is
>    like a virtual bus where one or multiple devices are present,
>    depending on the platform driver's policy. The platform session
>    makes the device resources of those devices available to the
>    client (the device driver). Under the hood, the platform driver
>    opens IO_MEM/IO_PORT/IRQ sessions at core.
>
>    In order to use Genode's existing arsenal of device drivers on
>    Linux, we need either a platform-driver version specifically adapted
>    for Linux (when re-using the Linux PCI driver), or investigate a way
>    to use our regular platform driver (including the PCI driver)
>    directly (this would be pretty cool!).
>
> I hope that the level of detail does not frighten you. We certainly
> don't expect you to complete all these stages. E.g., if completing stage
> 1 to 3, there would already be demonstratable results. Stage 4 certainly
> requires an investigation into the ways about the interplay of the IOMMU
> handling of the kernel with user-level device drivers. Stage 5 also has
> a atrong design aspect to it.
>
> It goes without saying that we won't leave you on your own. :-)
>
> Cheers
> Norman
>
> --
> Dr.-Ing. Norman Feske
> Genode Labs
>
> http://www.genode-labs.com · http://genode.org
>
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20170301/4c7c6cd2/attachment.html>