On Thu, Aug 25, 2011 at 7:29 AM, Sasha Levin <levinsasha928@xxxxxxxxx> wrote: > Hello, > > I am looking to implement an ivshmem device for KVM tools, the purpose > is to provide same functionality as QEMU and interoperability with QEMU. > > Going through the spec (I found here: > https://gitorious.org/nahanni/guest-code/blobs/master/device_spec.txt ) > and the code in QEMU I have gathered several questions, I'll be happy > for some help with it. > > 1. File handles and guest IDs are passed between the server and the > peers using sockets, is the protocol itself documented anywhere? I would > like to be able to work alongside QEMU servers/peers. > > 2. The spec describes DOORBELL as an array of DWORDs, when one guest > wants to poke a different guest it would write something into the offset > of the other guest in the DOORBELL array. > Looking at the implementation in QEMU, DOORBELL is one DWORD, when > writing to it the upper WORD is the guest id and the lower WORD is the > value. > What am I missing here? > > 3. There are 3 ways for guests to communicate between each other, and > I'm assuming all guests using the same SHM block must use the same > method. Is it safe to assume we'll always use ioeventfds as in the > implementation now? Guests can either access the shared memory region directly or use the server, so I would count that as 2 ways to share memory via ivshmem. Can you clarify what you mean by "ways for guests to communicate"? As for ioeventfds, they are an optional optimization to eventfds. We use eventfds currently, but since the guest VMs only see file descriptors (passed from the server) another mechanism could replace eventfds if there was some reason to. Cam -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
