GitLab

This is a boring but important commit that we need for
our glue code example (that is still in progress).

The main motiviation is: One kLCD (like a booting kLCD) may
want to create other threads to run kernel modules, and it
may want to grant them capabilities to resources. (Before
this, this wasn't possible - all kLCDs were isolated from
each other.) Another alternative (possibly better) for the
future is to allow threads to share cspaces. But we're
probably not there yet.

Adds the following to the kLIBLCD interface:

-- klcd_create_klcd - essentially creates another kernel
   thread and initializes the lcd-specific stuff like its
   cspace; the creator can then use lcd_cap_grant to grant
   this thread capabilities

-- klcd_create_module_klcd - creates a klcd (using
   klcd_create_klcd) and loads a kernel module for the klcd
   to run

-- klcd_destroy_module_klcd - destroys klcd (the kernel
   thread, etc.) and unloads the module

Adds test and an example group of modules that show how to use
this.

Kind of boring, but important. Now poised for doing some non-isolated
glue code.

Kind of bummer we have essentially three copies of the cspace-related
code - one in liblcd (isolated data store), one in kliblcd, and one in
the microkernel (real cspaces). Hopefully we can coalesce and reduce
the redundancy at some point.

The data store code for kliblcd is in virt/lcd-domains/kliblcd/dstore.c.
The interface is in include/lcd-domains/kliblcd.h.

Moved dstore into kliblcd. No build yet.

Small typo in cap doc.

Debug something else.

Updated dstore to do get/put.

Fixes build. liblcd tests pass.

Trying to make the code base saner for others to read through.

Tests are no longer ran every time you insert the microkernel. They are built
as a separate kernel module (in virt/lcd-domains/tests/lcd-tests.ko).

Ran tests again, and some of the LCD functional tests. All appears OK.

Just the capability code adapted for use inside the libkernel.

Basic tests passing. Coalesced a lot of the liblcd tests into
one spot (in liblcd/lcd/test.c).

Conflicts:
	drivers/Kconfig
	drivers/Makefile
	lib/Kconfig
	lib/Makefile
	lib/thc/thcsync.c
Resolved-by: Vikram Narayanan <vikram186@gmail.com>

moved ast to ccst code to new file from ccst.cpp, added stub code for stuff that needs to be implemented

Single threaded, no locks, no fancy NUMA/percpu.

Passing some simple examples. Added a memory management
example module, in test-mods/mm, that exercises a lot
of this new code.

1:

I moved in and adapted our existing guest virtual
paging code from kliblcd.c. I'm using statically
allocated bitmaps and arrays for tracking allocations
in the guest virtual and physical address spaces.
Using identity mapping for ease. (I decided not to
use Linux's page allocator since it's too intertwined
with the boot process - percpu variables, freeing
init mem, boot allocator, all kinds of complexity ...)
It might not be too hard to reimplement the buddy
allocator algorithms, since I had to include a
statically allocated array of struct pages anyway.

I've set aside about 16 MBs for dynamic page allocations,
but this can be changed using macros. You can allocate
1, 2, 4, 8, etc. pages at a time. (The slab allocator
requires this.)

2:

I finally broke down and set up boot info pages - 4
boot pages right now, can be adjusted with a macro.
Whoever boots the lcd needs to pack in information about the
lcd's address space, initial cspace, and so on. 4 pages
is enough to pack in information for larger modules
like the mm example.

3:

I moved liblcd to a separate directory, and hacked the
build system so that we can build liblcd as a static
library and link it with example modules.

liblcd/ contains lcd/, which has code for interacting
with the microkernel and my simple page allocator.

The Linux slab allocator is inside mm/, and some
needed dependencies are in lib/. I made very few
changes to the source code itself, but used some
preprocessor/compiler hacks to make everything work. See
Documentation/lcd-domains/liblcd.txt. I elided all of
the locking and made it single core, single NUMA node.
It's possible we'll see some bigs in the future, in code I haven't
excerised yet (will probably manifest themselves as
page faults).

Ideally, we should have a separate tree for liblcd
and building modules. That way we can avoid some of these
hacks (maybe not all).

4:

Updated a lot of the documentation in
Documentation/lcd-domains/.