|SUCCESS| [5/5] vhost_user: enable configure memory slots

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Thu Apr 2 15:50:12 CEST 2026


Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/162832

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-02

Looking at the series.patch file, I'll review the patches for correctness bugs, coding style violations, and guideline compliance.

880c4b3fb27b2a5c3d1e2f8a9b6d4e7c1a3f5e8b
Author: Pravin M Bathija <pravin.bathija at dell.com>
[PATCH 1/5] vhost: add user to mailmap and define to vhost hdr

This patch adds a mailmap entry and defines VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS.

> diff --git a/.mailmap b/.mailmap
> index 0e0d83e1c6..cc44e27036 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -1295,6 +1295,7 @@ Prateek Agarwal <prateekag at cse.iitb.ac.in>

[ ... ]

> diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
> index 2f7c4c0080..a7f9700538 100644
> --- a/lib/vhost/rte_vhost.h
> +++ b/lib/vhost/rte_vhost.h
> @@ -109,6 +109,10 @@ extern "C" {
>  #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
>  #endif
>  
> +#ifndef VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS
> +#define VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS 15
> +#endif
> +

Does this definition match the vhost-user specification? The use of
ifndef guards here seems unusual for protocol constants. Are these
meant to be overrideable, or should they be unconditional defines?

[PATCH 2/5] vhost_user: header defines for add/rem mem region

> diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
> index ef486545ba..f8d921f7f1 100644
> --- a/lib/vhost/vhost_user.h
> +++ b/lib/vhost/vhost_user.h
> @@ -67,6 +67,9 @@ typedef enum VhostUserRequest {
>  	VHOST_USER_POSTCOPY_END = 30,
>  	VHOST_USER_GET_INFLIGHT_FD = 31,
>  	VHOST_USER_SET_INFLIGHT_FD = 32,
> +	VHOST_USER_GET_MAX_MEM_SLOTS = 36,
> +	VHOST_USER_ADD_MEM_REG = 37,
> +	VHOST_USER_REM_MEM_REG = 38,

Are these enum values 36, 37, 38 consistent with the vhost-user
protocol specification? The gap between 32 and 36 suggests missing
entries. Should values 33-35 be documented or defined?

> +typedef struct VhostUserSingleMemReg {
> +	uint64_t padding;
> +	VhostUserMemoryRegion region;
> +} VhostUserSingleMemReg;

In VhostUserSingleMemReg, what is the purpose of the uint64_t padding
field? Is this for alignment or protocol compatibility? The name
"padding" suggests unused space, but explicit padding should be
documented.

[PATCH 3/5] vhost_user: support function defines for back-end

> +static int
> +async_dma_map_region(struct virtio_net *dev, struct rte_vhost_mem_region *reg, bool do_map)
> +{
> +	uint32_t i;
> +	int ret;
> +	uint64_t reg_start = reg->host_user_addr;
> +	uint64_t reg_end = reg_start + reg->size;
> +
> +	for (i = 0; i < dev->nr_guest_pages; i++) {
> +		struct guest_page *page = &dev->guest_pages[i];
> +
> +		/* Only process pages belonging to this region */
> +		if (page->host_user_addr < reg_start ||
> +		    page->host_user_addr >= reg_end)
> +			continue;

In async_dma_map_region(), does the calculation of reg_end handle the
case where reg_start + reg->size overflows? If reg->size is the maximum
uint64_t value, does this code overflow?

> +		if (do_map) {
> +			ret = rte_vfio_container_dma_map(RTE_VFIO_DEFAULT_CONTAINER_FD,
> +					page->host_user_addr,
> +					page->host_iova,
> +					page->size);
> +			if (ret) {
> +				if (rte_errno == ENODEV)
> +					return 0;
> +
> +				VHOST_CONFIG_LOG(dev->ifname, ERR, "DMA engine map failed");
> +				return -1;
> +			}

When async_dma_map_region() encounters a DMA map failure partway through
the loop, does this code unmap the regions that were successfully mapped
earlier in the loop? Does this cause a resource leak?

> @@ -808,8 +862,10 @@ hua_to_alignment(struct rte_vhost_memory *mem, void *ptr)
>  	uint32_t i;
>  	uintptr_t hua = (uintptr_t)ptr;
>  
> -	for (i = 0; i < mem->nregions; i++) {
> +	for (i = 0; i < VHOST_MEMORY_MAX_NREGIONS; i++) {
>  		r = &mem->regions[i];
> +		if (r->host_user_addr == 0)
> +			continue;

In hua_to_alignment(), why does the loop iterate up to
VHOST_MEMORY_MAX_NREGIONS instead of mem->nregions? With the new
dynamic region approach, can this cause unnecessary iterations through
uninitialized regions? Does checking host_user_addr == 0 reliably
identify unused slots?

> +static void
> +remove_guest_pages(struct virtio_net *dev, struct rte_vhost_mem_region *reg)
> +{
> +	uint64_t reg_start = reg->host_user_addr;
> +	uint64_t reg_end = reg_start + reg->size;
> +	uint32_t i, j = 0;
> +
> +	for (i = 0; i < dev->nr_guest_pages; i++) {
> +		if (dev->guest_pages[i].host_user_addr >= reg_start &&
> +		    dev->guest_pages[i].host_user_addr < reg_end)
> +			continue;
> +		if (j != i)
> +			dev->guest_pages[j] = dev->guest_pages[i];
> +		j++;
> +	}
> +	dev->nr_guest_pages = j;
> +}

In remove_guest_pages(), does this code handle partial pages at region
boundaries correctly? If a guest page spans across the reg_end boundary,
does the comparison dev->guest_pages[i].host_user_addr < reg_end
incorrectly exclude it?

> +static int
> +vhost_user_initialize_memory(struct virtio_net **pdev)
> +{
> +	struct virtio_net *dev = *pdev;
> +	int numa_node = SOCKET_ID_ANY;
> +
> +	if (dev->mem != NULL) {
> +		VHOST_CONFIG_LOG(dev->ifname, ERR,
> +			"memory already initialized, free it first");
> +		return -1;
> +	}

In vhost_user_initialize_memory(), when dev->mem is already initialized,
does this indicate a protocol violation or implementation bug? Should
this condition trigger cleanup of existing memory before returning an
error?

> +	dev->guest_pages = rte_zmalloc_socket(NULL,
> +				dev->max_guest_pages *
> +				sizeof(struct guest_page),
> +				RTE_CACHE_LINE_SIZE,
> +				numa_node);
> +	if (dev->guest_pages == NULL) {
> +		VHOST_CONFIG_LOG(dev->ifname, ERR,
> +			"failed to allocate memory for dev->guest_pages");
> +		return -1;
> +	}

Does vhost_user_initialize_memory() check if dev->guest_pages is already
allocated before calling rte_zmalloc_socket()? Can this code leak memory
if dev->guest_pages was previously allocated?

> +	dev->mem = rte_zmalloc_socket("vhost-mem-table", sizeof(struct rte_vhost_memory) +
> +		sizeof(struct rte_vhost_mem_region) * VHOST_MEMORY_MAX_NREGIONS, 0, numa_node);
> +	if (dev->mem == NULL) {
> +		VHOST_CONFIG_LOG(dev->ifname, ERR, "failed to allocate memory for dev->mem");
> +		rte_free(dev->guest_pages);
> +		dev->guest_pages = NULL;
> +		return -1;
> +	}

When vhost_user_initialize_memory() fails to allocate dev->mem, does
this code need to set dev->max_guest_pages = 0 in addition to freeing
dev->guest_pages?

[PATCH 4/5] vhost_user: Function defs for add/rem mem regions

> +static void
> +dev_invalidate_vrings(struct virtio_net **pdev)
> +{
> +	struct virtio_net *dev = *pdev;
> +	uint32_t i;
> +
> +	for (i = 0; i < dev->nr_vring; i++) {
> +		struct vhost_virtqueue *vq = dev->virtqueue[i];
> +
> +		if (!vq)
> +			continue;
> +
> +		if (vq->desc || vq->avail || vq->used) {
> +			/* vhost_user_lock_all_queue_pairs locked all qps */
> +			VHOST_USER_ASSERT_LOCK(dev, vq, VHOST_USER_ADD_MEM_REG);

In dev_invalidate_vrings(), the comment says
"vhost_user_lock_all_queue_pairs locked all qps" but does the code that
calls dev_invalidate_vrings() actually hold these locks? If not, does
this cause a race condition?

> +			/*
> +			 * If the memory table got updated, the ring addresses
> +			 * need to be translated again as virtual addresses have
> +			 * changed.
> +			 */
> +			vring_invalidate(dev, vq);
> +
> +			translate_ring_addresses(&dev, &vq);

After calling translate_ring_addresses() with &dev and &vq, why does the
code update the local dev pointer with *pdev = dev? Does
translate_ring_addresses() potentially reallocate the dev structure?

> +	/* make sure new region will fit */
> +	if (dev->mem->nregions >= VHOST_MEMORY_MAX_NREGIONS) {
> +		VHOST_CONFIG_LOG(dev->ifname, ERR, "too many memory regions already (%u)",
> +									dev->mem->nregions);
> +		goto close_msg_fds;
> +	}

In vhost_user_add_mem_reg(), is the comparison >= correct? If nregions
equals VHOST_MEMORY_MAX_NREGIONS - 1, can one more region be added, or
should this be >?

> +	/* Make sure no overlap in guest virtual address space */
> +	for (i = 0; i < dev->mem->nregions; i++) {
> +		struct rte_vhost_mem_region *current_region = &dev->mem->regions[i];
> +		uint64_t current_region_guest_start = current_region->guest_user_addr;
> +		uint64_t current_region_guest_end = current_region_guest_start
> +							+ current_region->size - 1;
> +		uint64_t proposed_region_guest_start = region->userspace_addr;
> +		uint64_t proposed_region_guest_end = proposed_region_guest_start
> +							+ region->memory_size - 1;

In vhost_user_add_mem_reg(), does the calculation of current_region_guest_end
and proposed_region_guest_end handle the case where size - 1 underflows
when size is 0? Can this comparison logic fail if a region has zero size?

> +	/* New region goes at the end of the contiguous array */
> +	struct rte_vhost_mem_region *reg = &dev->mem->regions[dev->mem->nregions];
> +
> +	reg->guest_phys_addr = region->guest_phys_addr;
> +	reg->guest_user_addr = region->userspace_addr;
> +	reg->size            = region->memory_size;
> +	reg->fd              = ctx->fds[0];
> +	ctx->fds[0]          = -1;

In vhost_user_add_mem_reg(), why is ctx->fds[0] set to -1 after copying
it to reg->fd? Is this to prevent double-close, or is there another
reason?

> +free_new_region:
> +	if (dev->async_copy && rte_vfio_is_enabled("vfio"))
> +		async_dma_map_region(dev, reg, false);
> +	remove_guest_pages(dev, reg);
> +	free_mem_region(reg);
> +	dev->mem->nregions--;

In the free_new_region error path of vhost_user_add_mem_reg(), does
decrementing dev->mem->nregions need to happen before calling
free_mem_region()? Can the ordering here cause issues?

> +static int
> +vhost_user_rem_mem_reg(struct virtio_net **pdev,
> +			struct vhu_msg_context *ctx,
> +			int main_fd __rte_unused)
> +{
> +	uint32_t i;
> +	struct virtio_net *dev = *pdev;
> +	struct VhostUserMemoryRegion *region = &ctx->msg.payload.memory_single.region;
> +
> +	if (dev->mem == NULL || dev->mem->nregions == 0) {
> +		VHOST_CONFIG_LOG(dev->ifname, ERR, "no memory regions to remove");
> +		close_msg_fds(ctx);
> +		return RTE_VHOST_MSG_RESULT_ERR;
> +	}

In vhost_user_rem_mem_reg(), when dev->mem->nregions is 0, does the code
need to verify that all regions are actually cleared (host_user_addr ==
0)? Can there be stale data in the regions array?

> +			/* Compact the regions array to keep it contiguous */
> +			if (i < dev->mem->nregions - 1) {
> +				memmove(&dev->mem->regions[i],
> +					&dev->mem->regions[i + 1],
> +					(dev->mem->nregions - 1 - i) *
> +					sizeof(struct rte_vhost_mem_region));
> +				memset(&dev->mem->regions[dev->mem->nregions - 1],
> +					0, sizeof(struct rte_vhost_mem_region));
> +			}

In vhost_user_rem_mem_reg(), after using memmove() to compact the array,
why is memset() called on the last element?


More information about the test-report mailing list