Gregory Haskins wrote: >>>> On Wed, May 16, 2007 at 2:39 PM, in message <[EMAIL PROTECTED]>, >>>> > Anthony Liguori <[EMAIL PROTECTED]> wrote: > >> Gregory Haskins wrote: >> >>>>>> On Wed, May 16, 2007 at 1:28 PM, in message <[EMAIL PROTECTED]>, >>>>>> >>>>>> >>> Anthony Liguori <[EMAIL PROTECTED]> 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel