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

[dpdklab at iol.unh.edu]

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

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-06

git sha: N/A (patch file review)
Author: Pravin M Bathija <pravin.bathija at dell.com>
Subject: [PATCH v12 1/5] vhost: add user to mailmap and define to vhost hdr

This patch series adds support for dynamically adding and removing memory
regions in the vhost-user backend. The changes introduce new message types
and handlers for memory slot configuration.

Overall Summary:
The patch series modifies the vhost-user backend to support dynamic memory
region management through new protocol messages. It refactors memory
initialization, adds support functions for per-region operations, and
enables the CONFIGURE_MEM_SLOTS protocol feature.

> 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>
>  Prathisna Padmasanan <prathisna.padmasanan at intel.com>
>  Praveen Kaligineedi <pkaligineedi at google.com>
>  Praveen Shetty <praveen.shetty at intel.com>
> +Pravin M Bathija <pravin.bathija at dell.com>
>  Pravin Pathak <pravin.pathak.dev at gmail.com> <pravin.pathak at intel.com>
>  Prince Takkar <ptakkar at marvell.com>
>  Priyalee Kushwaha <priyalee.kushwaha at intel.com>

[ ... ]

> 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,
>  	VHOST_USER_SET_STATUS = 39,
>  	VHOST_USER_GET_STATUS = 40,
>  } VhostUserRequest;

Does this ordering match the vhost-user specification? The enum values 36,
37, 38 appear between 32 and 39, leaving gaps. Are these the correct
protocol-defined values?

> @@ -91,6 +94,11 @@ typedef struct VhostUserMemory {
>  	VhostUserMemoryRegion regions[VHOST_MEMORY_MAX_NREGIONS];
>  } VhostUserMemory;
>  
> +typedef struct VhostUserSingleMemReg {
> +	uint64_t padding;
> +	VhostUserMemoryRegion region;
> +} VhostUserSingleMemReg;

Does the padding field align with the vhost-user wire protocol format? The
purpose of this padding field is unclear - is it required for proper
message alignment or protocol compatibility?

[ ... ]

> diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
> index 4bfb13fb98..9f1abb1842 100644
> --- a/lib/vhost/vhost_user.c
> +++ b/lib/vhost/vhost_user.c

[ ... ]

> -static void
> -async_dma_map(struct virtio_net *dev, bool do_map)
> +static int
> +async_dma_map_region(struct virtio_net *dev, struct rte_vhost_mem_region *reg, bool do_map)
>  {
> -	int ret = 0;
>  	uint32_t i;
> -	struct guest_page *page;
> +	int ret;
> +	uint64_t reg_start = reg->host_user_addr;
> +	uint64_t reg_end = reg_start + reg->size;
>  
> -	if (do_map) {
> -		for (i = 0; i < dev->nr_guest_pages; i++) {
> -			page = &dev->guest_pages[i];
> +	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;
> +
> +		if (do_map) {
>  			ret = rte_vfio_container_dma_map(RTE_VFIO_DEFAULT_CONTAINER_FD,
> -							 page->host_user_addr,
> -							 page->host_iova,
> -							 page->size);
> +					page->host_user_addr,
> +					page->host_iova,
> +					page->size);

Does this range check correctly handle pages that span the region
boundary? If page->host_user_addr is within the region but page->size
extends beyond reg_end, should the entire page be processed or rejected?

[ ... ]

> @@ -808,8 +837,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;

Is zero a valid host_user_addr? This check assumes zero indicates an
invalid/empty region, but could a legitimate memory mapping occur at
address zero in some scenarios?

[ ... ]

> +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;
> +}

Does this function need to check if pages span region boundaries? The same
concern applies as in async_dma_map_region() - if a page starts before
reg_start but extends into the region, or starts in the region but extends
beyond reg_end, should it be removed?

[ ... ]

> +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;
> +	}

Can this code safely assume dev->mem is NULL after vhost_backend_cleanup()
or during error recovery paths? Should this also check and handle the case
where dev->guest_pages is non-NULL but dev->mem is NULL?

[ ... ]

> +static int
> +vhost_user_add_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;
> +
> +	/* convert first region add to normal memory table set */
> +	if (dev->mem == NULL) {
> +		if (vhost_user_initialize_memory(pdev) < 0)
> +			goto close_msg_fds;
> +	}

After calling vhost_user_initialize_memory(), does pdev need to be
re-dereferenced? Some reallocation functions may move the dev pointer.

> +	/* 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;
> +	}

[ ... ]

> +	/* 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;
> +
> +	if (vhost_user_mmap_region(dev, reg, region->mmap_offset) < 0) {
> +		VHOST_CONFIG_LOG(dev->ifname, ERR, "failed to mmap region");
> +		if (reg->mmap_addr) {
> +			/* mmap succeeded but a later step (e.g. add_guest_pages)
> +			 * failed; undo the mapping and any guest-page entries.
> +			 */
> +			remove_guest_pages(dev, reg);
> +			free_mem_region(reg);
> +		} else {
> +			close(reg->fd);
> +			reg->fd = -1;
> +		}
> +		goto close_msg_fds;
> +	}
> +
> +	dev->mem->nregions++;

Does this code leak reg->fd if vhost_user_mmap_region() fails before
setting mmap_addr? The error path only closes reg->fd when mmap_addr is
NULL, but if the mmap itself succeeded and a later step in
vhost_user_mmap_region() failed, does free_mem_region() close the fd?

[ ... ]

> +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;
> +	}
> +
> +	for (i = 0; i < dev->mem->nregions; i++) {
> +		struct rte_vhost_mem_region *current_region = &dev->mem->regions[i];
> +
> +		/*
> +		 * According to the vhost-user specification:
> +		 * The memory region to be removed is identified by its GPA,
> +		 * user address and size. The mmap offset is ignored.
> +		 */
> +		if (region->userspace_addr == current_region->guest_user_addr
> +			&& region->guest_phys_addr == current_region->guest_phys_addr
> +			&& region->memory_size == current_region->size) {

Are the whitespace and line continuation choices here consistent with the
DPDK coding style? The logical AND operators should typically be at the
beginning of the continuation lines.

> +			if (dev->async_copy && rte_vfio_is_enabled("vfio"))
> +				async_dma_map_region(dev, current_region, false);

Can async_dma_map_region() fail here, and if so, should this function
continue with removal or return an error? The return value is not checked.

> +			remove_guest_pages(dev, current_region);
> +			free_mem_region(current_region);
> +
> +			/* 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));
> +			}

Does this memmove correctly handle all fields of rte_vhost_mem_region?
After moving regions, could any pointer fields within the structures become
invalid?