> We'll have to be smart about how the monitor handlers are
> mapped into the linear space of the monitor/guest, but I
> agree, some of it should be in there for best performance.
Why don't we simply keep the current way of mapping all pages
belonging to the fmw module into the guest context? Of course
we couldn't keep the identity mapping, but if we use properly
position independent code (-fPIC) and/or refrain from using global
variables, it should be easy to do ... [ That was my original
plan, b.t.w., I just didn't get around to do it :-/ ]
This way, we can just use normal C code to write the monitor
handlers, as long as we're careful not to rely on any libraries etc.
We'll probably have to think of a way how the monitor code can
access it's nexus structure (*some* global data must be accessible),
but an easy way would be to place a pointer (relative to the
monitor data segment) at the bottom of the monitor stack, accessible
via *(u32 *)(%esp & 0xfffff000) from the monitor ... (or even easier
place the nexus *itself* at the bottom of the monitor stack).
> The mon-->host context switch could get expensive if it's
> hit a lot.
Indeed.
> Anyways, just taking it one day at a time. :^)
Sure, I was just wondering ;-)
> Can't wait to see a few VMs running at once!
Maybe I can look into that; I think the proper way would be to
hang the host per-VM data off the 'file->private_data' hook.
This way, we'd need just one device node, and every separate
'open' of that node would create a new VM. Nevertheless, it'd
still be possible to share the VM across process boundaries
on user side, as you can pass an open file between processes
(either via inheriting, or else via sendmsg/recvmsg).
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
