diff options
| author | David Marchand <david.marchand@6wind.com> | 2015-06-16 17:43:34 +0200 |
|---|---|---|
| committer | Marc-André Lureau <marcandre.lureau@redhat.com> | 2015-10-24 18:03:18 +0200 |
| commit | 5105b1d8c2d1ad4a25b8806e86c0f012936b2eed (patch) | |
| tree | 95dcbbebbf05b3b91be876b0355e76d9b94d7cc6 /docs | |
| parent | 8c4ef202b901d25b88efc55398d4a76dfb2594de (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')
| -rw-r--r-- | docs/specs/ivshmem_device_spec.txt | 9 |
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). |