aboutsummaryrefslogtreecommitdiff
path: root/contrib/libvhost-user
AgeCommit message (Collapse)Author
2020-12-08libvhost-user: make it a meson subprojectMarc-André Lureau
By making libvhost-user a subproject, check it builds standalone (without the global QEMU cflags etc). Note that the library still relies on QEMU include/qemu/atomic.h and linux_headers/. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201125100640.366523-6-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-12-08libvhost-user: drop qemu/osdep.h dependencyMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201125100640.366523-5-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-12-08libvhost-user: remove qemu/compiler.h usageMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201125100640.366523-4-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-12-08libvhost-user: replace qemu/memfd.h usageMarc-André Lureau
Undo the damage from commit 5f9ff1eff3 ("libvhost-user: Support tracking inflight I/O in shared memory") which introduced glib dependency through osdep.h inclusion. libvhost-user.c tries to stay free from glib usage. Use glibc memfd_create directly when available (assumed so when MFD_ALLOW_SEALING is defined). A following commit will make the project standalone and check for memfd API at configure time, instead of a panic at runtime. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20201125100640.366523-3-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-12-08libvhost-user: replace qemu/bswap.h with glibc endian.hMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20201125100640.366523-2-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-11-17contrib/libvhost-user: Fix bad printf format specifiersAlexChen
We should use printf format specifier "%u" instead of "%d" for argument of type "unsigned int". Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Alex Chen <alex.chen@huawei.com> Message-Id: <5FA28106.6000901@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-11-12vhost-user: fix VHOST_USER_ADD/REM_MEM_REG truncationStefan Hajnoczi
QEMU currently truncates the mmap_offset field when sending VHOST_USER_ADD_MEM_REG and VHOST_USER_REM_MEM_REG messages. The struct layout looks like this: typedef struct VhostUserMemoryRegion { uint64_t guest_phys_addr; uint64_t memory_size; uint64_t userspace_addr; uint64_t mmap_offset; } VhostUserMemoryRegion; typedef struct VhostUserMemRegMsg { uint32_t padding; /* WARNING: there is a 32-bit hole here! */ VhostUserMemoryRegion region; } VhostUserMemRegMsg; The payload size is calculated as follows when sending the message in hw/virtio/vhost-user.c: msg->hdr.size = sizeof(msg->payload.mem_reg.padding) + sizeof(VhostUserMemoryRegion); This calculation produces an incorrect result of only 36 bytes. sizeof(VhostUserMemRegMsg) is actually 40 bytes. The consequence of this is that the final field, mmap_offset, is truncated. This breaks x86_64 TCG guests on s390 hosts. Other guest/host combinations may get lucky if either of the following holds: 1. The guest memory layout does not need mmap_offset != 0. 2. The host is little-endian and mmap_offset <= 0xffffffff so the truncation has no effect. Fix this by extending the existing 32-bit padding field to 64-bit. Now the padding reflects the actual compiler padding. This can be verified using pahole(1). Also document the layout properly in the vhost-user specification. The vhost-user spec did not document the exact layout. It would be impossible to implement the spec without looking at the QEMU source code. Existing vhost-user frontends and device backends continue to work after this fix has been applied. The only change in the wire protocol is that QEMU now sets hdr.size to 40 instead of 36. If a vhost-user implementation has a hardcoded size check for 36 bytes, then it will fail with new QEMUs. Both QEMU and DPDK/SPDK don't check the exact payload size, so they continue to work. Fixes: f1aeb14b0809e313c74244d838645ed25e85ea63 ("Transmit vhost-user memory regions individually") Cc: Raphael Norwitz <raphael.norwitz@nutanix.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20201109174355.1069147-1-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Fixes: f1aeb14b0809 ("Transmit vhost-user memory regions individually") Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2020-11-03libvhost-user: follow QEMU comment styleStefan Hajnoczi
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20201027173528.213464-2-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-10-23util/vhost-user-server: use static library in meson.buildStefan Hajnoczi
Don't compile contrib/libvhost-user/libvhost-user.c again. Instead build the static library once and then reuse it throughout QEMU. Also switch from CONFIG_LINUX to CONFIG_VHOST_USER, which is what the vhost-user tools (vhost-user-gpu, etc) do. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20200924151549.913737-14-stefanha@redhat.com [Added CONFIG_LINUX again because libvhost-user doesn't build on macOS. --Stefan] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-10-23libvhost-user: remove watch for kick_fd when de-initialize vu-devCoiby Xu
When the client is running in gdb and quit command is run in gdb, QEMU will still dispatch the event which will cause segment fault in the callback function. Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20200918080912.321299-3-coiby.xu@gmail.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-10-23libvhost-user: Allow vu_message_read to be replacedCoiby Xu
Allow vu_message_read to be replaced by one which will make use of the QIOChannel functions. Thus reading vhost-user message won't stall the guest. For slave channel, we still use the default vu_message_read. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20200918080912.321299-2-coiby.xu@gmail.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-09-29libvhost-user: return on error in vu_log_queue_fill()Stefan Hajnoczi
vu_panic() is not guaranteed to exit the program. Return early when errors are encountered. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200921113420.154378-3-stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-09-29libvhost-user: return early on virtqueue errorsStefan Hajnoczi
vu_panic() is not guaranteed to exit the program. Return early when errors are encountered. Note that libvhost-user does not have an "unmap" operation for mapped descriptors. Therefore it is correct to return without explicit cleanup. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200921113420.154378-2-stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-09-23qemu/atomic.h: rename atomic_ to qatomic_Stefan Hajnoczi
clang's C11 atomic_fetch_*() functions only take a C11 atomic type pointer argument. QEMU uses direct types (int, etc) and this causes a compiler error when a QEMU code calls these functions in a source file that also included <stdatomic.h> via a system header file: $ CC=clang CXX=clang++ ./configure ... && make ../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) Avoid using atomic_*() names in QEMU's atomic.h since that namespace is used by <stdatomic.h>. Prefix QEMU's APIs with 'q' so that atomic.h and <stdatomic.h> can co-exist. I checked /usr/include on my machine and searched GitHub for existing "qatomic_" users but there seem to be none. This patch was generated using: $ git grep -h -o '\<atomic\(64\)\?_[a-z0-9_]\+' include/qemu/atomic.h | \ sort -u >/tmp/changed_identifiers $ for identifier in $(</tmp/changed_identifiers); do sed -i "s%\<$identifier\>%q$identifier%g" \ $(git grep -I -l "\<$identifier\>") done I manually fixed line-wrap issues and misaligned rST tables. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200923105646.47864-1-stefanha@redhat.com>
2020-09-23libvhost-user: handle endianness as mandated by the specMarc Hartmayer
Since virtio existed even before it got standardized, the virtio standard defines the following types of virtio devices: + legacy device (pre-virtio 1.0) + non-legacy or VIRTIO 1.0 device + transitional device (which can act both as legacy and non-legacy) Virtio 1.0 defines the fields of the virtqueues as little endian, while legacy uses guest's native endian [1]. Currently libvhost-user does not handle virtio endianness at all, i.e. it works only if the native endianness matches with whatever is actually needed. That means things break spectacularly on big-endian targets. Let us handle virtio endianness for non-legacy as required by the virtio specification [1] and fence legacy virtio, as there is no safe way to figure out the needed endianness conversions for all cases. The fencing of legacy virtio devices is done in `vu_set_features_exec`. [1] https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-210003 Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Message-id: 20200901150019.29229-3-mhartmay@linux.ibm.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-09-17contrib/: fix some comment spelling errorszhaolichang
I found that there are many spelling errors in the comments of qemu, so I used the spellcheck tool to check the spelling errors and finally found some spelling errors in the contrib folder. Signed-off-by: zhaolichang <zhaolichang@huawei.com> Reviewed-by: Alex Bennee <alex.bennee@linaro.org> Message-Id: <20200917075029.313-11-zhaolichang@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-08-21contrib/libvhost-user: convert to MesonPaolo Bonzini
Since libqemuutil.a has been converted to Meson, the conversion is straightforward. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-07-27libvhost-user: Report descriptor index on panicPhilippe Mathieu-Daudé
We want to report the index of the descriptor, not its pointer. Fixes: 7b2e5c65f4 ("contrib: add libvhost-user") Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200723171935.18535-1-philmd@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-12libvhost-user: advertise vring featuresStefan Hajnoczi
libvhost-user implements several vring features without advertising them. There is no way for the vhost-user master to detect support for these features. Things more or less work today because QEMU assumes the vhost-user backend always implements certain feature bits like VIRTIO_RING_F_EVENT_IDX. This is not documented anywhere. This patch explicitly advertises features implemented in libvhost-user so that the vhost-user master does not need to make undocumented assumptions. Feature bits that libvhost-user now advertises can be removed from vhost-user-blk.c. Devices should not be responsible for advertising vring feature bits, that is libvhost-user's job. Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200529161338.456017-1-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2020-06-12Lift max ram slots limit in libvhost-userRaphael Norwitz
Historically, VMs with vhost-user devices could hot-add memory a maximum of 8 times. Now that the VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS protocol feature has been added, VMs with vhost-user backends which support this new feature can support a configurable number of ram slots up to the maximum supported by the target platform. This change adds VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS support for backends built with libvhost-user, and increases the number of supported ram slots from 8 to 32. Memory hot-add, hot-remove and postcopy migration were tested with the vhost-user-bridge sample. Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <1588533678-23450-11-git-send-email-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-12Support individual region unmap in libvhost-userRaphael Norwitz
When the VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS protocol feature is enabled, on memory hot-unplug qemu will transmit memory regions to remove individually using the new message VHOST_USER_REM_MEM_REG message. With this change, vhost-user backends build with libvhost-user can now unmap individual memory regions when receiving the VHOST_USER_REM_MEM_REG message. Qemu only sends VHOST_USER_REM_MEM_REG messages when the VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS feature is negotiated, and support for that feature has not yet been added in libvhost-user, this new functionality is not yet used. Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <1588533678-23450-10-git-send-email-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-12Support adding individual regions in libvhost-userRaphael Norwitz
When the VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS is enabled, qemu will transmit memory regions to a backend individually using the new message VHOST_USER_ADD_MEM_REG. With this change vhost-user backends built with libvhost-user can now map in new memory regions when VHOST_USER_ADD_MEM_REG messages are received. Qemu only sends VHOST_USER_ADD_MEM_REG messages when the VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS feature is negotiated, and since it is not yet supported in libvhost-user, this new functionality is not yet used. Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <1588533678-23450-9-git-send-email-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-12Support ram slot configuration in libvhost-userRaphael Norwitz
The VHOST_USER_GET_MAX_MEM_SLOTS message allows a vhost-user backend to specify a maximum number of ram slots it is willing to support. This change adds support for libvhost-user to process this message. For now the backend will reply with 8 as the maximum number of regions supported. libvhost-user does not yet support the vhost-user protocol feature VHOST_USER_PROTOCOL_F_CONFIGIRE_MEM_SLOTS, so qemu should never send the VHOST_USER_GET_MAX_MEM_SLOTS message. Therefore this new functionality is not currently used. Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <1588533678-23450-8-git-send-email-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2020-06-12Refactor out libvhost-user fault generation logicRaphael Norwitz
In libvhost-user, the incoming postcopy migration path for setting the backend's memory tables has become convolued. In particular, moving the logic which starts generating faults, having received the final ACK from qemu can be moved to a separate function. This simplifies the code substantially. This logic will also be needed by the postcopy path once the VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS feature is supported. Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <1588533678-23450-7-git-send-email-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2020-03-16misc: Replace zero-length arrays with flexible array member (automatic)Philippe Mathieu-Daudé
Description copied from Linux kernel commit from Gustavo A. R. Silva (see [3]): --v-- description start --v-- The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member [1], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being unadvertenly introduced [2] to the Linux codebase from now on. --^-- description end --^-- Do the similar housekeeping in the QEMU codebase (which uses C99 since commit 7be41675f7cb). All these instances of code were found with the help of the following Coccinelle script: @@ identifier s, m, a; type t, T; @@ struct s { ... t m; - T a[0]; + T a[]; }; @@ identifier s, m, a; type t, T; @@ struct s { ... t m; - T a[0]; + T a[]; } QEMU_PACKED; [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f [3] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1 Inspired-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-27libvhost-user: implement in-band notificationsJohannes Berg
Add support for VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS, but as it's not desired by default, don't enable it unless the device implementation opts in by returning it from its protocol features callback. Note that I updated vu_set_vring_err_exec(), but didn't add any sending of the VHOST_USER_SLAVE_VRING_ERR message as there's no write to the err_fd today either. This also adds vu_queue_notify_sync() which can be used to force a synchronous notification if inband notifications are supported. Previously, I had left out the slave->master direction handling of F_REPLY_ACK, this now adds some code to support it as well. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Message-Id: <20200123081708.7817-7-johannes@sipsolutions.net> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27libvhost-user: handle NOFD flag in call/kick/err betterJohannes Berg
The code here is odd, for example will it print out invalid file descriptor numbers that were never sent in the message. Clean that up a bit so it's actually possible to implement a device that uses polling. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Message-Id: <20200123081708.7817-5-johannes@sipsolutions.net> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27libvhost-user-glib: use g_main_context_get_thread_default()Johannes Berg
If we use NULL, we just get the main program default mainloop here. Using g_main_context_get_thread_default() has basically the same effect, but it lets us start different devices in different threads with different mainloops, which can be useful. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Message-Id: <20200123081708.7817-4-johannes@sipsolutions.net> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27libvhost-user-glib: fix VugDev main fd cleanupJohannes Berg
If you try to make a device implementation that can handle multiple connections and allow disconnections (which requires overriding the VHOST_USER_NONE handling), then glib will warn that we remove a src while it's still on the mainloop, and will poll() an FD that doesn't exist anymore. Fix this by making vug_source_new() require pairing with the new vug_source_destroy() so we can keep the GSource referenced in the meantime. Note that this requires calling the new API in vhost-user-input. vhost-user-gpu also uses vug_source_new(), but never seems to free the result at all, so I haven't changed anything there. Fixes: 8bb7ddb78a1c ("libvhost-user: add glib source helper") Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Message-Id: <20200123081708.7817-3-johannes@sipsolutions.net> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-02-27libvhost-user: implement VHOST_USER_PROTOCOL_F_REPLY_ACKJohannes Berg
This is really simple, since we know whether a response is already requested or not, so we can just send a (successful) response when there isn't one already. Given that, it's not all _that_ useful but the master can at least be sure the message was processed, and we can exercise more code paths using the example code. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Message-Id: <20200123081708.7817-2-johannes@sipsolutions.net> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-01-23libvhost-user: Fix some memtable remap casesDr. David Alan Gilbert
If a new setmemtable command comes in once the vhost threads are running, it will remap the guests address space and the threads will now be looking in the wrong place. Fortunately we're running this command under lock, so we can update the queue mappings so that threads will look in the new-right place. Note: This doesn't fix things that the threads might be doing without a lock (e.g. a readv/writev!) That's for another time. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-01-23contrib/libvhost-user: Protect slave fd with mutexDr. David Alan Gilbert
In future patches we'll be performing commands on the slave-fd driven by commands on queues, since those queues will be driven by individual threads we need to make sure they don't attempt to use the slave-fd for multiple commands in parallel. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-11-20libvhost-user: Zero memory allocated for VuVirtqInflightDescXie Yongji
Use a zero-initialized VuVirtqInflightDesc struct to avoid that scan-build reports that vq->resubmit_list[0].counter may be garbage value in vu_check_queue_inflights(). Fixes: 5f9ff1eff ("libvhost-user: Support tracking inflight I/O in shared memory") Reported-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Xie Yongji <xieyongji@baidu.com> Message-Id: <20191119075759.4334-1-xieyongji@baidu.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-09-04libvhost-user: introduce and use vu_has_protocol_feature()Johannes Berg
This simplifies the various has_feature() checks, we already have vu_has_feature() but it checks features, not protocol features. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Message-Id: <20190904065021.1360-1-johannes@sipsolutions.net> Reviewed-by: Tiwei Bie <tiwei.bie@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-09-04libvhost-user: fix SLAVE_SEND_FD handlingJohannes Berg
It doesn't look like this could possibly work properly since VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD is defined to 10, but the dev->protocol_features has a bitmap. I suppose the peer this was tested with also supported VHOST_USER_PROTOCOL_F_LOG_SHMFD, in which case the test would always be false, but nevertheless the code seems wrong. Use has_feature() to fix this. Fixes: d84599f56c82 ("libvhost-user: support host notifier") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Message-Id: <20190903200422.11693-1-johannes@sipsolutions.net> Reviewed-by: Tiwei Bie <tiwei.bie@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-07-04libvhost-user: implement VHOST_USER_PROTOCOL_F_MQStefan Hajnoczi
Existing vhost-user device backends, including vhost-user-scsi and vhost-user-blk, support multiqueue but libvhost-user currently does not advertise this. VHOST_USER_PROTOCOL_F_MQ enables the VHOST_USER_GET_QUEUE_NUM request needed for a vhost-user master to query the number of queues. For example, QEMU's vhost-user-net master depends on VHOST_USER_PROTOCOL_F_MQ for multiqueue. If you're wondering how any device backend with more than one virtqueue functions today, it's because device types with a fixed number of virtqueues do not require querying the number of queues. Therefore the vhost-user master for vhost-user-input with 2 virtqueues, for example, doesn't actually depend on VHOST_USER_PROTOCOL_F_MQ. It just enables virtqueues 0 and 1 without asking. Let there be multiqueue! Suggested-by: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190626074815.19994-4-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-07-04libvhost-user: support many virtqueuesStefan Hajnoczi
Currently libvhost-user is hardcoded to at most 8 virtqueues. The device backend should decide the number of virtqueues, not libvhost-user. This is important for multiqueue device backends where the guest driver needs an accurate number of virtqueues. This change breaks libvhost-user and libvhost-user-glib API stability. There is no stability guarantee yet, so make this change now and update all in-tree library users. This patch touches up vhost-user-blk, vhost-user-gpu, vhost-user-input, vhost-user-scsi, and vhost-user-bridge. If the device has a fixed number of queues that exact number is used. Otherwise the previous default of 8 virtqueues is used. vu_init() and vug_init() can now fail if malloc() returns NULL. I considered aborting with an error in libvhost-user but it should be safe to instantiate new vhost-user instances at runtime without risk of terminating the process. Therefore callers need to handle the vu_init() failure now. vhost-user-blk and vhost-user-scsi duplicate virtqueue index checks that are already performed by libvhost-user. This code would need to be modified to use max_queues but remove it completely instead since it's redundant. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190626074815.19994-3-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-07-04libvhost-user: add vmsg_set_reply_u64() helperStefan Hajnoczi
The VhostUserMsg request is reused as the reply by message processing functions. This is risky since request fields may corrupt the reply if the vhost-user message handler function forgets to re-initialize them. Changing this practice would be very invasive but we can introduce a helper function to make u64 payload replies safe. This also eliminates code duplication in message processing functions. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190626074815.19994-2-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-05-29vhost-user: add vhost_user_gpu_set_socket()Marc-André Lureau
Add a new vhost-user message to give a unix socket to a vhost-user backend for GPU display updates. Back when I started that work, I added a new GPU channel because the vhost-user protocol wasn't bidirectional. Since then, there is a vhost-user-slave channel for the slave to send requests to the master. We could extend it with GPU messages. However, the GPU protocol is quite orthogonal to vhost-user, thus I chose to have a new dedicated channel. See vhost-user-gpu.rst for the protocol details. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20190524130946.31736-2-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-22libvhost-user: fix -Werror=format= on ppc64Marc-André Lureau
That should fix the following warning: /home/pm215/qemu/contrib/libvhost-user/libvhost-user.c: In function ‘vu_set_mem_table_exec_postcopy’: /home/pm215/qemu/contrib/libvhost-user/libvhost-user.c:666:9: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 5 has type ‘__u64’ [-Werror=format=] DPRINT("%s: region %d: Registered userfault for %llx + %llx\n", ^ /home/pm215/qemu/contrib/libvhost-user/libvhost-user.c:666:9: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 6 has type ‘__u64’ [-Werror=format=] cc1: all warnings being treated as errors Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190514104126.6294-3-marcandre.lureau@redhat.com { kraxel: s/PRIu64/PRIx64/ ] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-22libvhost-user: fix cast warnings on 32 bitsMarc-André Lureau
Fixes warnings: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190514104126.6294-2-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-20libvhost-user: fix bad vu_log_writeLi Feng
Mark dirty as page, the step of each call is 1. Signed-off-by: Li Feng <fengli@smartx.com> Message-Id: <20190420091016.213160-1-fengli@smartx.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-05-10libvhost-user: add PROTOCOL_F_CONFIG if {set, get}_configMarc-André Lureau
Add the config protocol feature bit if the set_config & get_config callbacks are implemented. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20190503130034.24916-3-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-10libvhost-user: fix -Waddress-of-packed-memberMarc-André Lureau
/home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c: In function ‘vu_set_mem_table_exec_postcopy’: /home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c:546:31: warning: taking address of packed member of ‘struct VhostUserMsg’ may result in an unaligned pointer value [-Waddress-of-packed-member] 546 | VhostUserMemory *memory = &vmsg->payload.memory; | ^~~~~~~~~~~~~~~~~~~~~ /home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c: In function ‘vu_set_mem_table_exec’: /home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c:688:31: warning: taking address of packed member of ‘struct VhostUserMsg’ may result in an unaligned pointer value [-Waddress-of-packed-member] 688 | VhostUserMemory *memory = &vmsg->payload.memory; | ^~~~~~~~~~~~~~~~~~~~~ /home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c: In function ‘vu_set_vring_addr_exec’: /home/elmarco/src/qemu/contrib/libvhost-user/libvhost-user.c:817:36: warning: taking address of packed member of ‘struct VhostUserMsg’ may result in an unaligned pointer value [-Waddress-of-packed-member] 817 | struct vhost_vring_addr *vra = &vmsg->payload.addr; | ^~~~~~~~~~~~~~~~~~~ Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20190503130034.24916-2-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-07QEMU_PACKED: Remove gcc_struct attribute in Windows non x86 targetsCao Jiaxi
gcc_struct is for x86 only, and it generates an warning on ARM64 Clang/MinGW targets. Signed-off-by: Cao Jiaxi <driver1998@foxmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20190503003618.10089-1-driver1998@foxmail.com [PMM: dropped the slirp change as slirp is now a submodule] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-12libvhost-user: Support tracking inflight I/O in shared memoryXie Yongji
This patch adds support for VHOST_USER_GET_INFLIGHT_FD and VHOST_USER_SET_INFLIGHT_FD message to set/get shared buffer to/from qemu. Then backend can track inflight I/O in this buffer. Signed-off-by: Xie Yongji <xieyongji@baidu.com> Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Message-Id: <20190228085355.9614-5-xieyongji@baidu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-03-12libvhost-user: Introduce vu_queue_map_desc()Xie Yongji
Introduce vu_queue_map_desc() which should be independent with vu_queue_pop(); Signed-off-by: Xie Yongji <xieyongji@baidu.com> Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190228085355.9614-4-xieyongji@baidu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-03-12libvhost-user: Remove unnecessary FD flag check for event file descriptorsXie Yongji
The vu_check_queue_msg_file() has checked the FD flag. So let's delete the redundant check after it. Signed-off-by: Xie Yongji <xieyongji@baidu.com> Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Message-Id: <20190228085355.9614-3-xieyongji@baidu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-03-12libvhost-user: add vu_queue_unpop()Marc-André Lureau
vhost-user-input will make use of this function to undo some queue pop in case the virtio queue does not have enough room. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190308140454.32437-11-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-03-12libvhost-user-glib: export vug_source_new()Marc-André Lureau
Simplify the creation of FD sources for other users. This is just convenience to avoid duplicating similar code elsewhere. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190308140454.32437-10-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-18 04:20:59 +0000