Tree:
95aa4fdd58
10.1-testing
99888-virtio-zero-init-c9s
block
coverity
master
stable-0.10
stable-0.11
stable-0.12
stable-0.13
stable-0.14
stable-0.15
stable-1.0
stable-1.1
stable-1.2
stable-1.3
stable-1.4
stable-1.5
stable-1.6
stable-1.7
stable-10.0
stable-10.1
stable-10.2
stable-2.0
stable-2.1
stable-2.10
stable-2.11
stable-2.12
stable-2.2
stable-2.3
stable-2.4
stable-2.5
stable-2.6
stable-2.7
stable-2.8
stable-2.9
stable-3.0
stable-3.1
stable-4.0
stable-4.1
stable-4.2
stable-5.0
stable-6.0
stable-6.0-staging
stable-6.1
stable-7.2
stable-7.2-staging
stable-8.0
stable-8.0-staging
stable-8.1
stable-8.2
stable-9.0
stable-9.1
stable-9.2
staging
staging-0.0
staging-10.0
staging-10.1
staging-10.2
staging-7.2
staging-8.0
staging-8.1
staging-8.2
staging-9.0
staging-9.1
staging-9.2
staging-mjt-test
stsquad-hotfix
tracing
initial
release_0_10_0
release_0_10_1
release_0_10_2
release_0_5_1
release_0_6_0
release_0_6_1
release_0_7_0
release_0_7_1
release_0_8_1
release_0_8_2
release_0_9_0
release_0_9_1
staging-mjt-test
trivial-patches-pull-request
v0.1.0
v0.1.1
v0.1.3
v0.1.4
v0.1.5
v0.1.6
v0.10.0
v0.10.1
v0.10.2
v0.10.3
v0.10.4
v0.10.5
v0.10.6
v0.11.0
v0.11.0-rc0
v0.11.0-rc1
v0.11.0-rc2
v0.11.1
v0.12.0
v0.12.0-rc0
v0.12.0-rc1
v0.12.0-rc2
v0.12.1
v0.12.2
v0.12.3
v0.12.4
v0.12.5
v0.13.0
v0.13.0-rc0
v0.13.0-rc1
v0.13.0-rc2
v0.13.0-rc3
v0.14.0
v0.14.0-rc0
v0.14.0-rc1
v0.14.0-rc2
v0.14.1
v0.15.0
v0.15.0-rc0
v0.15.0-rc1
v0.15.0-rc2
v0.15.1
v0.2.0
v0.3.0
v0.4.0
v0.4.1
v0.4.2
v0.4.3
v0.4.4
v0.5.0
v0.5.1
v0.6.0
v0.6.1
v0.7.0
v0.7.1
v0.8.1
v0.8.2
v0.9.0
v0.9.1
v1.0
v1.0-rc0
v1.0-rc1
v1.0-rc2
v1.0-rc3
v1.0-rc4
v1.0.1
v1.1-rc0
v1.1-rc1
v1.1-rc2
v1.1.0
v1.1.0-rc2
v1.1.0-rc3
v1.1.0-rc4
v1.1.1
v1.1.2
v1.2.0
v1.2.0-rc0
v1.2.0-rc1
v1.2.0-rc2
v1.2.0-rc3
v1.2.1
v1.2.2
v1.3.0
v1.3.0-rc0
v1.3.0-rc1
v1.3.0-rc2
v1.3.1
v1.4.0
v1.4.0-rc0
v1.4.0-rc1
v1.4.0-rc2
v1.4.1
v1.4.2
v1.5.0
v1.5.0-rc0
v1.5.0-rc1
v1.5.0-rc2
v1.5.0-rc3
v1.5.1
v1.5.2
v1.5.3
v1.6.0
v1.6.0-rc0
v1.6.0-rc1
v1.6.0-rc2
v1.6.0-rc3
v1.6.1
v1.6.2
v1.7.0
v1.7.0-rc0
v1.7.0-rc1
v1.7.0-rc2
v1.7.1
v1.7.2
v10.0.0
v10.0.0-rc0
v10.0.0-rc1
v10.0.0-rc2
v10.0.0-rc3
v10.0.0-rc4
v10.0.1
v10.0.2
v10.0.3
v10.0.4
v10.0.5
v10.0.6
v10.0.7
v10.0.8
v10.1.0
v10.1.0-rc0
v10.1.0-rc1
v10.1.0-rc2
v10.1.0-rc3
v10.1.0-rc4
v10.1.1
v10.1.2
v10.1.3
v10.1.4
v10.2.0
v10.2.0-rc1
v10.2.0-rc2
v10.2.0-rc3
v10.2.0-rc4
v10.2.1
v2.0.0
v2.0.0-rc0
v2.0.0-rc1
v2.0.0-rc2
v2.0.0-rc3
v2.0.1
v2.0.2
v2.1.0
v2.1.0-rc0
v2.1.0-rc1
v2.1.0-rc2
v2.1.0-rc3
v2.1.0-rc4
v2.1.0-rc5
v2.1.1
v2.1.2
v2.1.3
v2.10.0
v2.10.0-rc0
v2.10.0-rc1
v2.10.0-rc2
v2.10.0-rc3
v2.10.0-rc4
v2.10.1
v2.10.2
v2.11.0
v2.11.0-rc0
v2.11.0-rc1
v2.11.0-rc2
v2.11.0-rc3
v2.11.0-rc4
v2.11.0-rc5
v2.11.1
v2.11.2
v2.12.0
v2.12.0-rc0
v2.12.0-rc1
v2.12.0-rc2
v2.12.0-rc3
v2.12.0-rc4
v2.12.1
v2.2.0
v2.2.0-rc0
v2.2.0-rc1
v2.2.0-rc2
v2.2.0-rc3
v2.2.0-rc4
v2.2.0-rc5
v2.2.1
v2.3.0
v2.3.0-rc0
v2.3.0-rc1
v2.3.0-rc2
v2.3.0-rc3
v2.3.0-rc4
v2.3.1
v2.4.0
v2.4.0-rc0
v2.4.0-rc1
v2.4.0-rc2
v2.4.0-rc3
v2.4.0-rc4
v2.4.0.1
v2.4.1
v2.5.0
v2.5.0-rc0
v2.5.0-rc1
v2.5.0-rc2
v2.5.0-rc3
v2.5.0-rc4
v2.5.1
v2.5.1.1
v2.6.0
v2.6.0-rc0
v2.6.0-rc1
v2.6.0-rc2
v2.6.0-rc3
v2.6.0-rc4
v2.6.0-rc5
v2.6.1
v2.6.2
v2.7.0
v2.7.0-rc0
v2.7.0-rc1
v2.7.0-rc2
v2.7.0-rc3
v2.7.0-rc4
v2.7.0-rc5
v2.7.1
v2.8.0
v2.8.0-rc0
v2.8.0-rc1
v2.8.0-rc2
v2.8.0-rc3
v2.8.0-rc4
v2.8.1
v2.8.1.1
v2.9.0
v2.9.0-rc0
v2.9.0-rc1
v2.9.0-rc2
v2.9.0-rc3
v2.9.0-rc4
v2.9.0-rc5
v2.9.1
v3.0.0
v3.0.0-rc0
v3.0.0-rc1
v3.0.0-rc2
v3.0.0-rc3
v3.0.0-rc4
v3.0.1
v3.1.0
v3.1.0-rc0
v3.1.0-rc1
v3.1.0-rc2
v3.1.0-rc3
v3.1.0-rc4
v3.1.0-rc5
v3.1.1
v3.1.1.1
v4.0.0
v4.0.0-rc0
v4.0.0-rc1
v4.0.0-rc2
v4.0.0-rc3
v4.0.0-rc4
v4.0.1
v4.1.0
v4.1.0-rc0
v4.1.0-rc1
v4.1.0-rc2
v4.1.0-rc3
v4.1.0-rc4
v4.1.0-rc5
v4.1.1
v4.2.0
v4.2.0-rc0
v4.2.0-rc1
v4.2.0-rc2
v4.2.0-rc3
v4.2.0-rc4
v4.2.0-rc5
v4.2.1
v5.0.0
v5.0.0-rc0
v5.0.0-rc1
v5.0.0-rc2
v5.0.0-rc3
v5.0.0-rc4
v5.0.1
v5.1.0
v5.1.0-rc0
v5.1.0-rc1
v5.1.0-rc2
v5.1.0-rc3
v5.2.0
v5.2.0-rc0
v5.2.0-rc1
v5.2.0-rc2
v5.2.0-rc3
v5.2.0-rc4
v6.0.0
v6.0.0-rc0
v6.0.0-rc1
v6.0.0-rc2
v6.0.0-rc3
v6.0.0-rc4
v6.0.0-rc5
v6.0.1
v6.1.0
v6.1.0-rc0
v6.1.0-rc1
v6.1.0-rc2
v6.1.0-rc3
v6.1.0-rc4
v6.1.1
v6.2.0
v6.2.0-rc0
v6.2.0-rc1
v6.2.0-rc2
v6.2.0-rc3
v6.2.0-rc4
v7.0.0
v7.0.0-rc0
v7.0.0-rc1
v7.0.0-rc2
v7.0.0-rc3
v7.0.0-rc4
v7.1.0
v7.1.0-rc0
v7.1.0-rc1
v7.1.0-rc2
v7.1.0-rc3
v7.1.0-rc4
v7.2.0
v7.2.0-rc0
v7.2.0-rc1
v7.2.0-rc2
v7.2.0-rc3
v7.2.0-rc4
v7.2.1
v7.2.10
v7.2.11
v7.2.12
v7.2.13
v7.2.14
v7.2.15
v7.2.16
v7.2.17
v7.2.18
v7.2.19
v7.2.2
v7.2.20
v7.2.21
v7.2.22
v7.2.3
v7.2.4
v7.2.5
v7.2.6
v7.2.7
v7.2.8
v7.2.9
v8.0.0
v8.0.0-rc0
v8.0.0-rc1
v8.0.0-rc2
v8.0.0-rc3
v8.0.0-rc4
v8.0.1
v8.0.2
v8.0.3
v8.0.4
v8.0.5
v8.1.0
v8.1.0-rc0
v8.1.0-rc1
v8.1.0-rc2
v8.1.0-rc3
v8.1.0-rc4
v8.1.1
v8.1.2
v8.1.3
v8.1.4
v8.1.5
v8.2.0
v8.2.0-rc0
v8.2.0-rc1
v8.2.0-rc2
v8.2.0-rc3
v8.2.0-rc4
v8.2.1
v8.2.10
v8.2.2
v8.2.3
v8.2.4
v8.2.5
v8.2.6
v8.2.7
v8.2.8
v8.2.9
v9.0.0
v9.0.0-rc0
v9.0.0-rc1
v9.0.0-rc2
v9.0.0-rc3
v9.0.0-rc4
v9.0.1
v9.0.2
v9.0.3
v9.0.4
v9.1.0
v9.1.0-rc0
v9.1.0-rc1
v9.1.0-rc2
v9.1.0-rc3
v9.1.0-rc4
v9.1.1
v9.1.2
v9.1.3
v9.2.0
v9.2.0-rc0
v9.2.0-rc1
v9.2.0-rc2
v9.2.0-rc3
v9.2.1
v9.2.2
v9.2.3
v9.2.4
${ noResults }
23 Commits (95aa4fdd58c50ba1d800bb106d73ef8a656e016e)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
7f27d20ded |
libvhost-user: Fix VHOST_USER_ADD_MEM_REG reply
With REPLY_NEEDED, libvhost-user sends both the acutal result and an
additional ACK reply for VHOST_USER_ADD_MEM_REG. This is incorrect, the
spec mandates that it behave the same with and without REPLY_NEEDED
because it always sends a reply.
Fixes:
|
4 years ago |
|
|
69a5daec06 |
libvhost-user: Fix VHOST_USER_GET_MAX_MEM_SLOTS reply
With REPLY_NEEDED, libvhost-user sends both the acutal result and an
additional ACK reply for VHOST_USER_GET_MAX_MEM_SLOTS. This is
incorrect, the spec mandates that it behave the same with and without
REPLY_NEEDED because it always sends a reply.
Fixes:
|
4 years ago |
|
|
d043e2db87 |
libvduse: Add support for reconnecting
To support reconnecting after restart or crash, VDUSE backend might need to resubmit inflight I/Os. This stores the metadata such as the index of inflight I/O's descriptors to a shm file so that VDUSE backend can restore them during reconnecting. Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Message-Id: <20220523084611.91-9-xieyongji@bytedance.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
4 years ago |
|
|
a6caeee811 |
libvduse: Add VDUSE (vDPA Device in Userspace) library
VDUSE [1] is a linux framework that makes it possible to implement software-emulated vDPA devices in userspace. This adds a library as a subproject to help implementing VDUSE backends in QEMU. [1] https://www.kernel.org/doc/html/latest/userspace-api/vduse.html Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Message-Id: <20220523084611.91-6-xieyongji@bytedance.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
4 years ago |
|
|
55116968de |
vfio-user: build library
add the libvfio-user library as a submodule. build it as a meson subproject. libvfio-user is distributed with BSD 3-Clause license and json-c with MIT (Expat) license Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com> Signed-off-by: John G Johnson <john.g.johnson@oracle.com> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: c2adec87958b081d1dc8775d4aa05c897912f025.1655151679.git.jag.raman@oracle.com [Changed submodule URL to QEMU's libvfio-user mirror on GitLab. The QEMU project mirrors its dependencies so that it can provide full source code even in the event that its dependencies become unavailable. Note that the mirror repo is manually updated, so please contact me to make newer libvfio-user commits available. If I become a bottleneck we can set up a cronjob. Updated scripts/meson-buildoptions.sh to match the meson_options.txt change. Failure to do so can result in scripts/meson-buildoptions.sh being modified by the build system later on and you end up with a dirty working tree. --Stefan] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> |
4 years ago |
|
|
467eeb0f80 |
libvhost-user: expose vu_request_to_string
This is useful for more human readable debug messages in vhost-user programs. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220321153037.3622127-9-alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> |
4 years ago |
|
|
a81d8d4a72 |
vhost-user: Don't pass file descriptor for VHOST_USER_REM_MEM_REG
The spec clarifies now that QEMU should not send a file descriptor in a request to remove a memory region. Change it accordingly. For libvhost-user, this is a bug fix that makes it compatible with rust-vmm's implementation that doesn't send a file descriptor. Keep accepting, but ignoring a file descriptor for compatibility with older QEMU versions. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20220407133657.155281-4-kwolf@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
4 years ago |
|
|
5ebfdeb212 |
libvhost-user: Fix extra vu_add/rem_mem_reg reply
Outside of postcopy mode, neither VHOST_USER_ADD_MEM_REG nor VHOST_USER_REM_MEM_REG are supposed to send a reply unless explicitly requested with the need_reply flag. Their current implementation always sends a reply, even if it isn't requested. This confuses the master because it will interpret the reply as a reply for the next message for which it actually expects a reply. need_reply is already handled correctly by vu_dispatch(), so just don't send a reply in the non-postcopy part of the message handler for these two commands. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20220407133657.155281-3-kwolf@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> |
4 years ago |
|
|
ef0f4bda2e |
Use QEMU_SANITIZE_THREAD
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> |
4 years ago |
|
|
eb99baa9b3 |
libvhost-user: Map shared RAM with MAP_NORESERVE to support virtio-mem with hugetlb
For fd-based shared memory, MAP_NORESERVE is only effective for hugetlb, otherwise it's ignored. Older Linux versions that didn't support reservation of huge pages ignored MAP_NORESERVE completely. The first client to mmap a hugetlb fd without MAP_NORESERVE will trigger reservation of huge pages for the whole mmapped range. There are two cases to consider: 1) QEMU mapped RAM without MAP_NORESERVE We're not dealing with a sparse mapping, huge pages for the whole range have already been reserved by QEMU. An additional mmap() without MAP_NORESERVE won't have any effect on the reservation. 2) QEMU mapped RAM with MAP_NORESERVE We're delaing with a sparse mapping, no huge pages should be reserved. Further mappings without MAP_NORESERVE should be avoided. For 1), it doesn't matter if we set MAP_NORESERVE or not, so we can simply set it. For 2), we'd be overriding QEMUs decision and trigger reservation of huge pages, which might just fail if there are not sufficient huge pages around. We must map with MAP_NORESERVE. This change is required to support virtio-mem with hugetlb: a virtio-mem device mapped into the guest physical memory corresponds to a sparse memory mapping and QEMU maps this memory with MAP_NORESERVE. Whenever memory in that sparse region will be accessed by the VM, QEMU populates huge pages for the affected range by preallocating memory and handling any preallocation errors gracefully. So let's map shared RAM with MAP_NORESERVE. As libvhost-user only supports Linux, there shouldn't be anything to take care of in regard of other OS support. Without this change, libvhost-user will fail mapping the region if there are currently not enough huge pages to perform the reservation: fv_panic: libvhost-user: region mmap error: Cannot allocate memory Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Raphael Norwitz <raphael.norwitz@nutanix.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20220111123939.132659-1-david@redhat.com> Acked-by: Raphael Norwitz <raphael.norwitz@nutanix.com> |
5 years ago |
|
|
4fafedc9da |
libvhost-user: handle removal of identical regions
Today if QEMU (or any other VMM) has sent multiple copies of the same region to a libvhost-user based backend and then attempts to remove the region, only one instance of the region will be removed, leaving stale copies of the region in dev->regions[]. This change resolves this by having vu_rem_mem_reg() iterate through all regions in dev->regions[] and delete all matching regions. Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <20220117041050.19718-7-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> |
5 years ago |
|
|
b906a23c33 |
libvhost-user: prevent over-running max RAM slots
When VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS support was added to libvhost-user, no guardrails were added to protect against QEMU attempting to hot-add too many RAM slots to a VM with a libvhost-user based backed attached. This change adds the missing error handling by introducing a check on the number of RAM slots the device has available before proceeding to process the VHOST_USER_ADD_MEM_REG message. Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <20220117041050.19718-6-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> |
5 years ago |
|
|
fa3d5483f0 |
libvhost-user: fix VHOST_USER_REM_MEM_REG not closing the fd
We end up not closing the file descriptor, resulting in leaking one
file descriptor for each VHOST_USER_REM_MEM_REG message.
Fixes:
|
5 years ago |
|
|
4fd5ca829a |
libvhost-user: Simplify VHOST_USER_REM_MEM_REG
Let's avoid having to manually copy all elements. Copy only the ones necessary to close the hole and perform the operation in-place without a second array. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <20220117041050.19718-4-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> |
5 years ago |
|
|
9f4e63491b |
libvhost-user: Add vu_add_mem_reg input validation
Today if multiple FDs are sent from the VMM to the backend in a VHOST_USER_ADD_MEM_REG message, one FD will be mapped and the remaining FDs will be leaked. Therefore if multiple FDs are sent we report an error and fail the operation, closing all FDs in the message. Likewise in case the VMM sends a message with a size less than that of a memory region descriptor, we add a check to gracefully report an error and fail the operation rather than crashing. Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <20220117041050.19718-3-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> |
5 years ago |
|
|
316ee11144 |
libvhost-user: Add vu_rem_mem_reg input validation
Today if multiple FDs are sent from the VMM to the backend in a VHOST_USER_REM_MEM_REG message, one FD will be unmapped and the remaining FDs will be leaked. Therefore if multiple FDs are sent we report an error and fail the operation, closing all FDs in the message. Likewise in case the VMM sends a message with a size less than that of a memory region descriptor, we add a check to gracefully report an error and fail the operation rather than crashing. Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <20220117041050.19718-2-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> |
5 years ago |
|
|
6889eb2d43 |
libvhost-user: fix VHOST_USER_REM_MEM_REG skipping mmap_addr
We end up not copying the mmap_addr of all existing regions, resulting
in a SEGFAULT once we actually try to map/access anything within our
memory regions.
Fixes:
|
5 years ago |
|
|
4fe29344be |
libvhost-user: fix -Werror=format= warnings with __u64 fields
../subprojects/libvhost-user/libvhost-user.c:1070:12: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘__u64’ {aka ‘long long unsigned int’} [-Werror=format=]
1070 | DPRINT(" desc_user_addr: 0x%016" PRIx64 "\n", vra->desc_user_addr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
| |
| __u64 {aka long long unsigned int}
Rather than using %llx, which may fail if __u64 is declared differently
elsewhere, let's just cast the values. Feel free to propose a better solution!
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210505151313.203258-2-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
5 years ago |
|
|
3f55f97b14 |
meson: fix meson 0.58 warning with libvhost-user subproject
Meson now checks that subprojects do not access files from parent project. While we all agree this is best practice, libvhost-user also want to share a few headers with QEMU, and libvhost-user isn't really a standalone project at this point (although this is making the dependency a bit more explicit). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210505151313.203258-1-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
5 years ago |
|
|
0ba781957e |
build-sys: add libvhost-user missing dependencies
This help fixing static compilation issues. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210114125605.1227742-4-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
6 years ago |
|
|
29ce0d35e1 |
libvhost-user: Include poll.h instead of sys/poll.h
Musl libc complains about it's wrong usage.
In file included from ../subprojects/libvhost-user/libvhost-user.h:20,
from ../subprojects/libvhost-user/libvhost-user-glib.h:19,
from ../subprojects/libvhost-user/libvhost-user-glib.c:15:
/usr/include/sys/poll.h:1:2: error: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Werror=cpp]
1 | #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
| ^~~~~~~
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210118063808.12471-3-jiaxun.yang@flygoat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
|
6 years ago |
|
|
e0193568da |
libvhost-user: add a simple link test without glib
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201125100640.366523-8-marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> |
6 years ago |
|
|
0df750e9d3 |
libvhost-user: make it a meson subproject
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> |
6 years ago |