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

Anthony Liguori
2007-05-16T19:10:36Z

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