GSoc-2017: Platforms - Microkernelizing Linux, help needed
blackskygg at ...9...
Wed Mar 1 16:58:41 CET 2017
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
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:
> 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. :-)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users