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

Anthony Liguori
2007-05-17T16:13:57Z

Rusty Russell wrote:
> On Wed, 2007-05-16 at 14:10 -0500, Anthony Liguori wrote:
>
>> For the host, you can probably stay entirely within QEMU. Interguest
>> communication would be a bit tricky but guest->host communication is
>> real simple.
>>
>
> guest->host is always simple. But it'd be great if it didn't matter to
> the guest whether it's talking to the host or another guest.
>
> I think shared memory is an obvious start, but it's not enough for
> inter-guest where they can't freely access each other's memory. So you
> really want a ring-buffer of descriptors with a hypervisor-assist to say
> "read/write this into the memory referred to by that descriptor".
>

I think this is getting a little ahead of ourselves. An example of this
idea is pretty straight-forward but it gets more complicated when trying
to support the existing memory sharing mechanisms on various
hypervisors. There are a few cases to consider:

1) The target VM can access all of the memory of the guest VM with no
penalty. This is the case when going from guest=>QEMU in KVM or going
from guest=>kernel (ignoring highmem) in KVM. For this, you can send
arbitrary memory to the host.

2) The target VM can access all of the memory of the guest VM with a
penalty. For guest=>other userspace process in KVM, an mmap() would be
required. This would work for Xen provided the target VM was domain-0
but it would incur a xc_map_foreign_range().

3) The target and source VM can only share memory based on an existing
pool. This is the guest with Xen and grant tables.

I think an API that covers these three cases is a bit tricky and will
likely make undesired trade-offs. I think it's easier to start out
focusing on the "low-speed" case where there's a mandatory data-copy.

You can still pass gntref's or PFNs down this transport if you like and
perhaps down the road we'll find that we can make a common interface for
doing this sort of thing.

Regards,

Anthony Liguori

> I think this can be done as a simple variation of the current schemes in
> existence.
>
> But I'm shutting up until I have some demonstration code 8)
>
>
>> 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.
>>
>
> Hmm, I was going to leave that unspecified. One thing at a time...
>
> Rusty.
>
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel