Re: GSoC project about virtualization using Hurd mechanisms

[olafBuddenhagen]

Hi,

You replied off-list; I assume that was inadvertent...

On Wed, Apr 16, 2008 at 01:17:27AM +0200, zhengda wrote:
> olafBuddenhagen@gmx.net wrote:

>> Well, for one -- as I said -- the hypervisor could be completely
>> transparent, just emulating the "real" device, so the subhurd doesn't
>> even know it's not talking to the kernel. This is more complicated on
>> the hypervisor side, but has the advantage of requiring no
>> modifications in the guest system using it.
>>   
> pfinet needs to call device_open() to open the device, to call
> device_set_filter() to set the filter, and to call device_write() to
> write the data. As I can see, these 3 functions are IPC. To implement
> the transparent hypervisor, pfinet have to get the port  (the device
> port) given by the hypervisor. After that, the hypervisor can pretend
> itself as the device, receiving  and sending data. Is it right?

Exactly :-)

>> But I initially thought even in the para-virtualized case, where the
>> system is modified to talk to a special device with an explicitely
>> virtual interface rather than something looking like the kernel
>> device, an indepentant hypervisor still could be easier than a normal
>> translator, because it can offer an interface that is explicitely
>> meant to be used by independant systems...
>>
>> However, thinking a bit more about it, I realize that this notion was
>> probably wrong. What make translators tricky is the lookup and
>> authentication stuff. But the subhurd will get a port ready for use
>> (authenticated against the user running the subhurd). And once you
>> have the actual port, a translator can implement any kind of
>> interface it likes -- it could actually be the very same interface
>> that a standalone hypervisor would have!
>>
>> So unless I am missing something important now, my previous statement
>> was false. Having the hypervisor (or the BPF server) implemented as a
>> translator should not make things more complicated in any way :-)
>>   
> I wonder if it is possible to implement the BPF translator by using
> the  similar way as above (by somehow modifying the device port in
> pfinet).

Sorry, don't know what you mean here :-(

> After talking so much with you, I think I'm clear what I should do in
> this project. Basically, I want to implement the virtual network, but
> by using the  general approach (which can be also used by subhurd).
> The communication between different pfinets: using the BPF translator
> and the hypervisor (I prefer the BPF translator). Let the user choose
> which pfinet to use: using some mechanisms mentioned  in the project
> of Server Overriding Mechanism.

Sounds like a good plan :-)

We will have to look at the BPF vs. full hypervisor question in more
detail yet, but that doesn't affect the rest of the task...

> If someone has picked the project of Server Overriding Mechanism, [...]

Nobody has.

> Anyway, I can make the virtual network work after the project :-)

Indeed, I have some doubt that we should consider the virtual network
itself part of the GSoC project; but the prerequisites necessary for it
are generally useful :-) And once they are in place, I think the network
itself shouldn't be a big deal anymore...

> And do I need to change the proposal in the GoSC application webpage?

Well, you can't change the proposal in the webapp anymore, but you could
put an updated version on some external location. Not sure it's
necessary; but it could help a bit with evaluation...

-antrik-