Re: Lightweight virtualization - the rump approach

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Sun, 16 May 2010 16:09:03 +0300, Antti Kantee <pooka%cs.hut.fi@localhost> 
wrote:
> On Sat May 15 2010 at 22:41:29 +0200, Jean-Yves Migeon wrote:
>> Let's take an example; suppose that $somefs_support is integrated in 
>> NetBSD (like ZFS, NILFS, ...), what kind of additional work is needed
to 
>> go from mount_somefs to rump_somefs (thinking about all _KERNEL 
>> functions that are missing).
> 
> Well, first of all you're falling into the microkernel two-faceted trap
> again with your example ;)
> 
> rump_somefs is the *userspace* part.  Actually, all the rump_somefs are
> somewhat misnamed.  I think p2k_somefs would be a better name, but it's
> not really worth changing anymore.

I am probably missing something then; p2k being a translation layer, it is
shared between the different rump_* parts. As such, I considered
(wrongfully maybe?) that the interface/protocol communication is not
expected to change with regards to rump_* components. Which means that
having rump_somefs support is a matter of making its code run in userland,
and talk with the kernel through p2k (which remains untouched in this
case).

>> >Well, maybe.  That does make some sense if you already are capable
>> >of hosting domU's.  I never found Xen very convenient for my use case
>> >(occasional testing) because it needs a special dom0 kernel.  Why
isn't
>> >that stuff in GENERIC again?  IIRC there were some device support
issues
>> >years ago, but do they still remain?
>> 
>> At least for x86, key parts of MD code are handled differently, 
>> especially pmap(9), locore's boot stuff, and some bus_space code. So
you 
>> have #ifdef/inline thingies, which are, as you have noticed, not that 
>> well modular-friendly.
>> 
>> Making this MD part dynamic would need some clean up in x86+xen, and 
>> probably introduce function pointers to make the thing more dynamic and

>> "stable", like Linux and the big paravirt_ops.
>> 
>> dom0 vs domU is another story, it is basically a reduced version of 
>> dom0, cleaned from all drivers and code that are not required for a 
>> domU. May become unnecessary when kernel becomes more and more modular:
>> -rwxr-xr-x  1 root  wheel   11M Apr 28 09:21 netbsd_XEN3PAE_DOM0
>> -rwxr-xr-x  1 root  wheel  4,1M Apr 28 09:21 netbsd_XEN3PAE_DOMU
> 
> I don't care about domU differences that much (in my use case), it's the
> dom0 which is the showstopper.  Frankly, I'd love to be able to run my
> anita testing with xen instead of qemu, since unaccelerated qemu tends
> to be quite slow (and my laptop doesn't support VT-x anyway).

IIUC:
1 - you want GENERIC to be bootable directly as a dom0, just to be able to
launch Xen PV guests
2 - perform anita test on a GENERIC kernel launched within a domU

Correct?

> *) unless we're talking about the shaken cocktail with equal parts gin,
> maraschino, chartreuse and lime juice.

Heh, first time I heard from that one. Probably not the last, though ;)

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost