Ulrich Weigand wrote:
> > 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).
That sounds like a great idea. I completely forgot about the
private_data pointer. Go nuts.
FWIW, the Rubino book has a reminder to set it back to NULL
in the release method before the file structure is destroyed
by the kernel.
Some good ideas on how to deal with the monitor code that
needs to mapped in. I need to research PIC code some to
understand how it all works. Agreed that we need to be
able to use standard C and tools to generate the code.
I have some other ideas I'll look into as well. More later.
If possible, I'd like to get it right without a need for
a re-write. Anyways, ultimately I'd like to map in more
then just the monitor virtualization handlers. It'd be nice
to conditionally map in components of the hardware emulation.
Like imagine if a guest disk driver was reading non-DMA through
the IO ports. If we could put the non read()/write() oriented
stuff in the monitor and just read from or write to a buffer,
we crank up the performance incredibly. We should have a way
that creates the smallest monitor footprint in the guest address
space, so we have the most flexibility.
Sorry for how messy monitor.c is. I'll clean that up and
access all the .S fields with one structure pointer. It's
all containted in monitor.c so I figured might as well
give you what I have.
-Kevin
