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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > ------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
