Revision tags: v8.2.2, v7.2.10 |
|
#
0fa6344c |
| 14-Feb-2024 |
David Hildenbrand <david@redhat.com> |
libvhost-user: Bump up VHOST_USER_MAX_RAM_SLOTS to 509
Let's support up to 509 mem slots, just like vhost in the kernel usually does and the rust vhost-user implementation recently [1] started doing
libvhost-user: Bump up VHOST_USER_MAX_RAM_SLOTS to 509
Let's support up to 509 mem slots, just like vhost in the kernel usually does and the rust vhost-user implementation recently [1] started doing. This is required to properly support memory hotplug, either using multiple DIMMs (ACPI supports up to 256) or using virtio-mem.
The 509 used to be the KVM limit, it supported 512, but 3 were used for internal purposes. Currently, KVM supports more than 512, but it usually doesn't make use of more than ~260 (i.e., 256 DIMMs + boot memory), except when other memory devices like PCI devices with BARs are used. So, 509 seems to work well for vhost in the kernel.
Details can be found in the QEMU change that made virtio-mem consume up to 256 mem slots across all virtio-mem devices. [2]
509 mem slots implies 509 VMAs/mappings in the worst case (even though, in practice with virtio-mem we won't be seeing more than ~260 in most setups).
With max_map_count under Linux defaulting to 64k, 509 mem slots still correspond to less than 1% of the maximum number of mappings. There are plenty left for the application to consume.
[1] https://github.com/rust-vmm/vhost/pull/224 [2] https://lore.kernel.org/all/20230926185738.277351-1-david@redhat.com/
Reviewed-by: Raphael Norwitz <raphael@enfabrica.net> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20240214151701.29906-3-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
d884e272 |
| 14-Feb-2024 |
David Hildenbrand <david@redhat.com> |
libvhost-user: Dynamically allocate memory for memory slots
Let's prepare for increasing VHOST_USER_MAX_RAM_SLOTS by dynamically allocating dev->regions. We don't have any ABI guarantees (not dynami
libvhost-user: Dynamically allocate memory for memory slots
Let's prepare for increasing VHOST_USER_MAX_RAM_SLOTS by dynamically allocating dev->regions. We don't have any ABI guarantees (not dynamically linked), so we can simply change the layout of VuDev.
Let's zero out the memory, just as we used to do.
Reviewed-by: Raphael Norwitz <raphael@enfabrica.net> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20240214151701.29906-2-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.2.2, v7.2.10 |
|
#
0fa6344c |
| 14-Feb-2024 |
David Hildenbrand <david@redhat.com> |
libvhost-user: Bump up VHOST_USER_MAX_RAM_SLOTS to 509
Let's support up to 509 mem slots, just like vhost in the kernel usually does and the rust vhost-user implementation recently [1] started doing
libvhost-user: Bump up VHOST_USER_MAX_RAM_SLOTS to 509
Let's support up to 509 mem slots, just like vhost in the kernel usually does and the rust vhost-user implementation recently [1] started doing. This is required to properly support memory hotplug, either using multiple DIMMs (ACPI supports up to 256) or using virtio-mem.
The 509 used to be the KVM limit, it supported 512, but 3 were used for internal purposes. Currently, KVM supports more than 512, but it usually doesn't make use of more than ~260 (i.e., 256 DIMMs + boot memory), except when other memory devices like PCI devices with BARs are used. So, 509 seems to work well for vhost in the kernel.
Details can be found in the QEMU change that made virtio-mem consume up to 256 mem slots across all virtio-mem devices. [2]
509 mem slots implies 509 VMAs/mappings in the worst case (even though, in practice with virtio-mem we won't be seeing more than ~260 in most setups).
With max_map_count under Linux defaulting to 64k, 509 mem slots still correspond to less than 1% of the maximum number of mappings. There are plenty left for the application to consume.
[1] https://github.com/rust-vmm/vhost/pull/224 [2] https://lore.kernel.org/all/20230926185738.277351-1-david@redhat.com/
Reviewed-by: Raphael Norwitz <raphael@enfabrica.net> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20240214151701.29906-3-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
d884e272 |
| 14-Feb-2024 |
David Hildenbrand <david@redhat.com> |
libvhost-user: Dynamically allocate memory for memory slots
Let's prepare for increasing VHOST_USER_MAX_RAM_SLOTS by dynamically allocating dev->regions. We don't have any ABI guarantees (not dynami
libvhost-user: Dynamically allocate memory for memory slots
Let's prepare for increasing VHOST_USER_MAX_RAM_SLOTS by dynamically allocating dev->regions. We don't have any ABI guarantees (not dynamically linked), so we can simply change the layout of VuDev.
Let's zero out the memory, just as we used to do.
Reviewed-by: Raphael Norwitz <raphael@enfabrica.net> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20240214151701.29906-2-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.2.2, v7.2.10 |
|
#
0fa6344c |
| 14-Feb-2024 |
David Hildenbrand <david@redhat.com> |
libvhost-user: Bump up VHOST_USER_MAX_RAM_SLOTS to 509
Let's support up to 509 mem slots, just like vhost in the kernel usually does and the rust vhost-user implementation recently [1] started doing
libvhost-user: Bump up VHOST_USER_MAX_RAM_SLOTS to 509
Let's support up to 509 mem slots, just like vhost in the kernel usually does and the rust vhost-user implementation recently [1] started doing. This is required to properly support memory hotplug, either using multiple DIMMs (ACPI supports up to 256) or using virtio-mem.
The 509 used to be the KVM limit, it supported 512, but 3 were used for internal purposes. Currently, KVM supports more than 512, but it usually doesn't make use of more than ~260 (i.e., 256 DIMMs + boot memory), except when other memory devices like PCI devices with BARs are used. So, 509 seems to work well for vhost in the kernel.
Details can be found in the QEMU change that made virtio-mem consume up to 256 mem slots across all virtio-mem devices. [2]
509 mem slots implies 509 VMAs/mappings in the worst case (even though, in practice with virtio-mem we won't be seeing more than ~260 in most setups).
With max_map_count under Linux defaulting to 64k, 509 mem slots still correspond to less than 1% of the maximum number of mappings. There are plenty left for the application to consume.
[1] https://github.com/rust-vmm/vhost/pull/224 [2] https://lore.kernel.org/all/20230926185738.277351-1-david@redhat.com/
Reviewed-by: Raphael Norwitz <raphael@enfabrica.net> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20240214151701.29906-3-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
d884e272 |
| 14-Feb-2024 |
David Hildenbrand <david@redhat.com> |
libvhost-user: Dynamically allocate memory for memory slots
Let's prepare for increasing VHOST_USER_MAX_RAM_SLOTS by dynamically allocating dev->regions. We don't have any ABI guarantees (not dynami
libvhost-user: Dynamically allocate memory for memory slots
Let's prepare for increasing VHOST_USER_MAX_RAM_SLOTS by dynamically allocating dev->regions. We don't have any ABI guarantees (not dynamically linked), so we can simply change the layout of VuDev.
Let's zero out the memory, just as we used to do.
Reviewed-by: Raphael Norwitz <raphael@enfabrica.net> Acked-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20240214151701.29906-2-david@redhat.com> Tested-by: Mario Casquero <mcasquer@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0, v8.1.2 |
|
#
d4eb5038 |
| 16-Oct-2023 |
Hanna Czenczek <hreitz@redhat.com> |
vhost-user: Fix protocol feature bit conflict
The VHOST_USER_PROTOCOL_F_XEN_MMAP feature bit was defined in f21e95ee97d, which has been part of qemu's 8.1.0 release. However, it seems it was never
vhost-user: Fix protocol feature bit conflict
The VHOST_USER_PROTOCOL_F_XEN_MMAP feature bit was defined in f21e95ee97d, which has been part of qemu's 8.1.0 release. However, it seems it was never added to qemu's code, but it is well possible that it is already used by different front-ends outside of qemu (i.e., Xen).
VHOST_USER_PROTOCOL_F_SHARED_OBJECT in contrast was added to qemu's code in 16094766627, but never defined in the vhost-user specification. As a consequence, both bits were defined to be 17, which cannot work.
Regardless of whether actual code or the specification should take precedence, F_XEN_MMAP is already part of a qemu release, while F_SHARED_OBJECT is not. Therefore, bump the latter to take number 18 instead of 17, and add this to the specification.
Take the opportunity to add at least a little note on the VhostUserShared structure to the specification. This structure is referenced by the new commands introduced in 16094766627, but was not defined.
Fixes: 160947666276c5b7f6bca4d746bcac2966635d79 ("vhost-user: add shared_object msg") Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Message-Id: <20231016083201.23736-1-hreitz@redhat.com> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0, v8.1.2 |
|
#
d4eb5038 |
| 16-Oct-2023 |
Hanna Czenczek <hreitz@redhat.com> |
vhost-user: Fix protocol feature bit conflict
The VHOST_USER_PROTOCOL_F_XEN_MMAP feature bit was defined in f21e95ee97d, which has been part of qemu's 8.1.0 release. However, it seems it was never
vhost-user: Fix protocol feature bit conflict
The VHOST_USER_PROTOCOL_F_XEN_MMAP feature bit was defined in f21e95ee97d, which has been part of qemu's 8.1.0 release. However, it seems it was never added to qemu's code, but it is well possible that it is already used by different front-ends outside of qemu (i.e., Xen).
VHOST_USER_PROTOCOL_F_SHARED_OBJECT in contrast was added to qemu's code in 16094766627, but never defined in the vhost-user specification. As a consequence, both bits were defined to be 17, which cannot work.
Regardless of whether actual code or the specification should take precedence, F_XEN_MMAP is already part of a qemu release, while F_SHARED_OBJECT is not. Therefore, bump the latter to take number 18 instead of 17, and add this to the specification.
Take the opportunity to add at least a little note on the VhostUserShared structure to the specification. This structure is referenced by the new commands introduced in 16094766627, but was not defined.
Fixes: 160947666276c5b7f6bca4d746bcac2966635d79 ("vhost-user: add shared_object msg") Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Message-Id: <20231016083201.23736-1-hreitz@redhat.com> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0, v8.1.2 |
|
#
d4eb5038 |
| 16-Oct-2023 |
Hanna Czenczek <hreitz@redhat.com> |
vhost-user: Fix protocol feature bit conflict
The VHOST_USER_PROTOCOL_F_XEN_MMAP feature bit was defined in f21e95ee97d, which has been part of qemu's 8.1.0 release. However, it seems it was never
vhost-user: Fix protocol feature bit conflict
The VHOST_USER_PROTOCOL_F_XEN_MMAP feature bit was defined in f21e95ee97d, which has been part of qemu's 8.1.0 release. However, it seems it was never added to qemu's code, but it is well possible that it is already used by different front-ends outside of qemu (i.e., Xen).
VHOST_USER_PROTOCOL_F_SHARED_OBJECT in contrast was added to qemu's code in 16094766627, but never defined in the vhost-user specification. As a consequence, both bits were defined to be 17, which cannot work.
Regardless of whether actual code or the specification should take precedence, F_XEN_MMAP is already part of a qemu release, while F_SHARED_OBJECT is not. Therefore, bump the latter to take number 18 instead of 17, and add this to the specification.
Take the opportunity to add at least a little note on the VhostUserShared structure to the specification. This structure is referenced by the new commands introduced in 16094766627, but was not defined.
Fixes: 160947666276c5b7f6bca4d746bcac2966635d79 ("vhost-user: add shared_object msg") Signed-off-by: Hanna Czenczek <hreitz@redhat.com> Message-Id: <20231016083201.23736-1-hreitz@redhat.com> Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
ce0f3b03 |
| 02-Oct-2023 |
Albert Esteve <aesteve@redhat.com> |
libvhost-user: handle shared_object msg
In the libvhost-user library we need to handle VHOST_USER_GET_SHARED_OBJECT requests, and add helper functions to allow sending messages to interact with the
libvhost-user: handle shared_object msg
In the libvhost-user library we need to handle VHOST_USER_GET_SHARED_OBJECT requests, and add helper functions to allow sending messages to interact with the virtio shared objects hash table.
Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-5-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
ce0f3b03 |
| 02-Oct-2023 |
Albert Esteve <aesteve@redhat.com> |
libvhost-user: handle shared_object msg
In the libvhost-user library we need to handle VHOST_USER_GET_SHARED_OBJECT requests, and add helper functions to allow sending messages to interact with the
libvhost-user: handle shared_object msg
In the libvhost-user library we need to handle VHOST_USER_GET_SHARED_OBJECT requests, and add helper functions to allow sending messages to interact with the virtio shared objects hash table.
Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-5-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
ce0f3b03 |
| 02-Oct-2023 |
Albert Esteve <aesteve@redhat.com> |
libvhost-user: handle shared_object msg
In the libvhost-user library we need to handle VHOST_USER_GET_SHARED_OBJECT requests, and add helper functions to allow sending messages to interact with the
libvhost-user: handle shared_object msg
In the libvhost-user library we need to handle VHOST_USER_GET_SHARED_OBJECT requests, and add helper functions to allow sending messages to interact with the virtio shared objects hash table.
Signed-off-by: Albert Esteve <aesteve@redhat.com> Message-Id: <20231002065706.94707-5-aesteve@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0, v8.0.3, v7.2.4 |
|
#
f8ed3648 |
| 13-Jun-2023 |
Manos Pitsidianakis <manos.pitsidianakis@linaro.org> |
vhost-user: fully use new backend/frontend naming
Slave/master nomenclature was replaced with backend/frontend in commit 1fc19b65279a ("vhost-user: Adopt new backend naming")
This patch replaces al
vhost-user: fully use new backend/frontend naming
Slave/master nomenclature was replaced with backend/frontend in commit 1fc19b65279a ("vhost-user: Adopt new backend naming")
This patch replaces all remaining uses of master and slave in the codebase.
Signed-off-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <20230613080849.2115347-1-manos.pitsidianakis@linaro.org> 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>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2 |
|
#
ca858a5f |
| 21-Mar-2023 |
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> |
vhost-user-blk-server: notify client about disk resize
Currently block_resize qmp command is simply ignored by vhost-user-blk export. So, the block-node is successfully resized, but virtio config is
vhost-user-blk-server: notify client about disk resize
Currently block_resize qmp command is simply ignored by vhost-user-blk export. So, the block-node is successfully resized, but virtio config is unchanged and guest doesn't see that disk is resized.
Let's handle the resize by modifying the config and notifying the guest appropriately.
After this comment, lsblk in linux guest with attached vhost-user-blk-pci device shows new size immediately after block_resize QMP command on vhost-user exported block node.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20230321201323.3695923-1-vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2 |
|
#
ca858a5f |
| 21-Mar-2023 |
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> |
vhost-user-blk-server: notify client about disk resize
Currently block_resize qmp command is simply ignored by vhost-user-blk export. So, the block-node is successfully resized, but virtio config is
vhost-user-blk-server: notify client about disk resize
Currently block_resize qmp command is simply ignored by vhost-user-blk export. So, the block-node is successfully resized, but virtio config is unchanged and guest doesn't see that disk is resized.
Let's handle the resize by modifying the config and notifying the guest appropriately.
After this comment, lsblk in linux guest with attached vhost-user-blk-pci device shows new size immediately after block_resize QMP command on vhost-user exported block node.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20230321201323.3695923-1-vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2 |
|
#
ca858a5f |
| 21-Mar-2023 |
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> |
vhost-user-blk-server: notify client about disk resize
Currently block_resize qmp command is simply ignored by vhost-user-blk export. So, the block-node is successfully resized, but virtio config is
vhost-user-blk-server: notify client about disk resize
Currently block_resize qmp command is simply ignored by vhost-user-blk export. So, the block-node is successfully resized, but virtio config is unchanged and guest doesn't see that disk is resized.
Let's handle the resize by modifying the config and notifying the guest appropriately.
After this comment, lsblk in linux guest with attached vhost-user-blk-pci device shows new size immediately after block_resize QMP command on vhost-user exported block node.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-Id: <20230321201323.3695923-1-vsementsov@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.0.0-rc1, v8.0.0-rc0 |
|
#
e608feed |
| 08-Feb-2023 |
Maxime Coquelin <maxime.coquelin@redhat.com> |
libvhost-user: Adopt new backend naming
The Vhost-user specification changed feature and request naming from _SLAVE_ to _BACKEND_.
This patch adopts the new naming convention.
Signed-off-by: Maxim
libvhost-user: Adopt new backend naming
The Vhost-user specification changed feature and request naming from _SLAVE_ to _BACKEND_.
This patch adopts the new naming convention.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Message-Id: <20230208203259.381326-3-maxime.coquelin@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.0.0-rc1, v8.0.0-rc0 |
|
#
e608feed |
| 08-Feb-2023 |
Maxime Coquelin <maxime.coquelin@redhat.com> |
libvhost-user: Adopt new backend naming
The Vhost-user specification changed feature and request naming from _SLAVE_ to _BACKEND_.
This patch adopts the new naming convention.
Signed-off-by: Maxim
libvhost-user: Adopt new backend naming
The Vhost-user specification changed feature and request naming from _SLAVE_ to _BACKEND_.
This patch adopts the new naming convention.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Message-Id: <20230208203259.381326-3-maxime.coquelin@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
e7ee4fe2 |
| 19-Dec-2022 |
Marcel Holtmann <marcel@holtmann.org> |
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvh
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvhost-user.o libvhost-user.c: In function ‘vu_queue_pop’: libvhost-user.c:2763:19: error: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Werror=sign-compare] 2763 | if (vq->inuse >= vq->vring.num) { | ^~ libvhost-user.c: In function ‘vu_queue_rewind’: libvhost-user.c:2808:13: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare] 2808 | if (num > vq->inuse) { | ^
Instead of casting the comparision to unsigned int, just make the inuse field unsigned int in the fist place.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Message-Id: <20221219175337.377435-8-marcel@holtmann.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
e7ee4fe2 |
| 19-Dec-2022 |
Marcel Holtmann <marcel@holtmann.org> |
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvh
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvhost-user.o libvhost-user.c: In function ‘vu_queue_pop’: libvhost-user.c:2763:19: error: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Werror=sign-compare] 2763 | if (vq->inuse >= vq->vring.num) { | ^~ libvhost-user.c: In function ‘vu_queue_rewind’: libvhost-user.c:2808:13: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare] 2808 | if (num > vq->inuse) { | ^
Instead of casting the comparision to unsigned int, just make the inuse field unsigned int in the fist place.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Message-Id: <20221219175337.377435-8-marcel@holtmann.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
e7ee4fe2 |
| 19-Dec-2022 |
Marcel Holtmann <marcel@holtmann.org> |
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvh
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvhost-user.o libvhost-user.c: In function ‘vu_queue_pop’: libvhost-user.c:2763:19: error: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Werror=sign-compare] 2763 | if (vq->inuse >= vq->vring.num) { | ^~ libvhost-user.c: In function ‘vu_queue_rewind’: libvhost-user.c:2808:13: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare] 2808 | if (num > vq->inuse) { | ^
Instead of casting the comparision to unsigned int, just make the inuse field unsigned int in the fist place.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Message-Id: <20221219175337.377435-8-marcel@holtmann.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
e7ee4fe2 |
| 19-Dec-2022 |
Marcel Holtmann <marcel@holtmann.org> |
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvh
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvhost-user.o libvhost-user.c: In function ‘vu_queue_pop’: libvhost-user.c:2763:19: error: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Werror=sign-compare] 2763 | if (vq->inuse >= vq->vring.num) { | ^~ libvhost-user.c: In function ‘vu_queue_rewind’: libvhost-user.c:2808:13: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare] 2808 | if (num > vq->inuse) { | ^
Instead of casting the comparision to unsigned int, just make the inuse field unsigned int in the fist place.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Message-Id: <20221219175337.377435-8-marcel@holtmann.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
e7ee4fe2 |
| 19-Dec-2022 |
Marcel Holtmann <marcel@holtmann.org> |
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvh
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvhost-user.o libvhost-user.c: In function ‘vu_queue_pop’: libvhost-user.c:2763:19: error: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Werror=sign-compare] 2763 | if (vq->inuse >= vq->vring.num) { | ^~ libvhost-user.c: In function ‘vu_queue_rewind’: libvhost-user.c:2808:13: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare] 2808 | if (num > vq->inuse) { | ^
Instead of casting the comparision to unsigned int, just make the inuse field unsigned int in the fist place.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Message-Id: <20221219175337.377435-8-marcel@holtmann.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
e7ee4fe2 |
| 19-Dec-2022 |
Marcel Holtmann <marcel@holtmann.org> |
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvh
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvhost-user.o libvhost-user.c: In function ‘vu_queue_pop’: libvhost-user.c:2763:19: error: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Werror=sign-compare] 2763 | if (vq->inuse >= vq->vring.num) { | ^~ libvhost-user.c: In function ‘vu_queue_rewind’: libvhost-user.c:2808:13: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare] 2808 | if (num > vq->inuse) { | ^
Instead of casting the comparision to unsigned int, just make the inuse field unsigned int in the fist place.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Message-Id: <20221219175337.377435-8-marcel@holtmann.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
e7ee4fe2 |
| 19-Dec-2022 |
Marcel Holtmann <marcel@holtmann.org> |
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvh
libvhost-user: Switch to unsigned int for inuse field in struct VuVirtq
It seems there is no need to keep the inuse field signed and end up with compiler warnings for sign-compare.
CC libvhost-user.o libvhost-user.c: In function ‘vu_queue_pop’: libvhost-user.c:2763:19: error: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Werror=sign-compare] 2763 | if (vq->inuse >= vq->vring.num) { | ^~ libvhost-user.c: In function ‘vu_queue_rewind’: libvhost-user.c:2808:13: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare] 2808 | if (num > vq->inuse) { | ^
Instead of casting the comparision to unsigned int, just make the inuse field unsigned int in the fist place.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Message-Id: <20221219175337.377435-8-marcel@holtmann.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|