aboutsummaryrefslogtreecommitdiff
path: root/docs/specs
diff options
context:
space:
mode:
authorDavid Marchand <david.marchand@6wind.com>2015-06-16 17:43:34 +0200
committerMarc-André Lureau <marcandre.lureau@redhat.com>2015-10-24 18:03:18 +0200
commit5105b1d8c2d1ad4a25b8806e86c0f012936b2eed (patch)
tree95dcbbebbf05b3b91be876b0355e76d9b94d7cc6 /docs/specs
parent8c4ef202b901d25b88efc55398d4a76dfb2594de (diff)
ivshmem: add check on protocol version in QEMU
Send a protocol version as the first message from server, clients must close communication if they don't support this protocol version. Older QEMUs should be fine with this change in the protocol since they overrides their own vm_id on reception of an id associated to no eventfd. Signed-off-by: David Marchand <david.marchand@6wind.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> [use fifo_update_and_get()] Reviewed-by: Claudio Fontana <claudio.fontana@huawei.com>
Diffstat (limited to 'docs/specs')
-rw-r--r--docs/specs/ivshmem_device_spec.txt9
1 files changed, 6 insertions, 3 deletions
diff --git a/docs/specs/ivshmem_device_spec.txt b/docs/specs/ivshmem_device_spec.txt
index 12f338e186..3435116b37 100644
--- a/docs/specs/ivshmem_device_spec.txt
+++ b/docs/specs/ivshmem_device_spec.txt
@@ -64,6 +64,8 @@ It creates a shared memory object then waits for clients to connect on a unix
socket.
For each client (QEMU process) that connects to the server:
+- the server sends a protocol version, if client does not support it, the client
+ closes the communication,
- the server assigns an ID for this client and sends this ID to him as the first
message,
- the server sends a fd to the shared memory object to this client,
@@ -86,9 +88,10 @@ been provided in qemu.git/contrib/ivshmem-client for debug.
*QEMU as an ivshmem client*
-At initialisation, when creating the ivshmem device, QEMU gets its ID from the
-server then makes it available through BAR0 IVPosition register for the VM to
-use (see 'PCI device registers' subsection).
+At initialisation, when creating the ivshmem device, QEMU first receives a
+protocol version and closes communication with server if it does not match.
+Then, QEMU gets its ID from the server then makes it available through BAR0
+IVPosition register for the VM to use (see 'PCI device registers' subsection).
QEMU then uses the fd to the shared memory to map it to BAR2.
eventfds for all other clients received from the server are stored to implement
BAR0 Doorbell register (see 'PCI device registers' subsection).