On 20/05/16 16:49, Vincent Schwarzer (Redacted sender vincent.schwarzer
for DMARC) wrote:
Hey,
I have some questions regarding the architecture of Rumpkernels / Rumprun.
1. To my understanding the platform of Rumprun on Xen is MiniOS which
provides the memory space , the platform / hardware threads and scheduling
for them?
Not really. For example, I completely rewrote the scheduler to be
reasonably efficient for the characteristics of a rump kernel (many
infrequently-to-never running threads) and very heavily hacked the page
allocator to support aligned allocation, among other things. The Xen
platform still sort of boots with a now-bastardized MiniOS, the hw
platform has never really done that. Part of the problem was that
MiniOS does too much in places we're not really interested in, and too
little in places which we are interested in (see
rewriting/bastardization). That's not to say that things weren't
heavily influenced by the Xen MiniOS, and all credit to them for making
our lives a lot easier.
2. If the system resides in one address space how is it possible that
according to the rumpctrl tool rumprun has 3 processes (proc.0 to proc.2)?
I always thought that Kernel and Application are sharing one address
space. Where the kernel and application have their own threads all
belonging to one main process.
Does this mean that Rumprun is having three distinct address spaces (0:
kernel 1:? and 2: application) since each process requires his own address
space and there are context switches between them? But if this is the case
why are Pseudo System Calls used since there is basically a user / kernel
space by dividing the system into three distinct address spaces.
No. The processes you see are *rump kernel* processes. They have
nothing to do with address spaces (a rump kernel does not know about
address spaces!). A process is just a way of saying which namespace is
being used. For example, file descriptor 0 is different for process n
and process n+1. For remote clients processes also represent
connections to the rump kernel (think e.g. connect()).
3. Does Rumprun use virtual memory since x86_64 architecture mandates
virtual memory usage for long mode operations?
Yes and no. It maps virtual memory 1:1 to physical memory. The
pagetable is even generated with an awk script ;)
I mostly-wrote support for x86_64 to have a real page table, but I
didn't get around to finishing it, mostly because it doesn't give any
benefit apart from being able to trap ridiculously incorrect pointer
dereferences.
4. If not how is the compatibility with applications using mmap on
rumprun to map and unmap memory maintained?
It isn't, at least not in the strictest sense.
If you study what is required by the complete implementation of
mmap(MAP_FILE), you'll find that it's utterly complicated. Now,
granted, we have most of that complexity in a rump kernel for free
already since we use the real vnode pager from NetBSD (*). However, for
it to really work, we'd need to teach a rump kernel about virtual
memory. That's not something I'm willing to see done, because if you
really want to use an application which really wants to use memory
mapping, you can go use some other OS-y thing.
*) I tried rewriting the vnode pager to make it simpler for the boundary
conditions required by a rump kernel, but gave up after a few years
since it was a hopeless task to get all argument handling correct, and
just punted to using the full vnode pager, even if it does a bit of
extra work
