Re: [PATCH/RFC 7/9] Virtual network guest device driver

[Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Gregory Haskins wrote:
>>>> On Wed, May 16, 2007 at  2:39 PM, in message <464B4FEB.7070300-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
>>>>         
> Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote: 
>   
>> Gregory Haskins wrote:
>>     
>>>>>> On Wed, May 16, 2007 at  1:28 PM, in message <464B3F20.4030904-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
>>>>>>         
>>>>>>             
>>> Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote: 
>>>   
>>>       
>>>> What do you think about a socket interface?  I'm not sure how discovery 
>>>> would work yet, but there are a few PV socket implementations for Xen at 
>>>> the moment.
>>>>     
>>>>         
>>> FYI: The work I am doing is exactly that.  I am going to extend host- based 
>>>       
>> unix domain sockets up to the KVM guest.  Not sure how well it will work yet, 
>> as I had to lay the LAPIC work down first for IO- completion.
>>     
>>>   
>>>       
>> Do you plan on introducing a new address family in the guest?
>>     
>
> Well, since I had to step back and lay some infrastructure groundwork I haven't vetted this approach yet...so its possible what I am about to say is relatively naive:  But my primary application is to create a guest-kernel to host IVMC.

This is quite easy with KVM.  I like the approach that vmchannel has 
taken.  A simple PCI device.  That gives you a discovery mechanism for 
shared memory and an interrupt and then you can just implement a ring 
queue using those mechanisms (along with a PIO port for signaling from 
the guest to the host).  So given that underlying mechanism, the 
question is how to expose that within the guest kernel/userspace and 
within the host.

For the host, you can probably stay entirely within QEMU.  Interguest 
communication would be a bit tricky but guest->host communication is 
real simple.

You could stop at exposing the channel as a socket within the guest 
kernel/userspace.  That would work, but you may also want to expose the 
ring queue within the kernel at least if there are consumers that need 
to avoid the copy.

A tricky bit of this is how to do discovery.  If you want to support 
interguest communication, it's not really sufficient to just use strings 
since they identifiers would have to be unique throughout the entire 
system.  Maybe you just leave it as a guest=>host channel and be done 
with it.

Regards,

Anthony Liguori

>   For that you can just think of the guest as any other process on the host, and it will just use the sockets normally as any host-process would.  There might be some thunking that has to happen to deal with gpa vs va, etc, but otherwise its a standard consumer.  If you want to extend IVMC up to guest-userspace, I think making some kind of new socket family makes sense in the guests stack.  PF_VIRT like someone else suggested, for instance.  But since I dont need this type of IVMC I haven't really thought about this too much.
>
> -Greg
>
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/