aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorJohn Levon <john.levon@nutanix.com>2021-06-02 16:08:14 +0100
committerGitHub <noreply@github.com>2021-06-02 16:08:14 +0100
commit57684de8240fce4a277301a86a803842338762af (patch)
treeea1066e2ae4de34bd7b77f9fb7a26af40848b52f /include
parentb8234a75d9ec2c95cb889c0cef27927f34ad9cbc (diff)
downloadlibvfio-user-57684de8240fce4a277301a86a803842338762af.zip
libvfio-user-57684de8240fce4a277301a86a803842338762af.tar.gz
libvfio-user-57684de8240fce4a277301a86a803842338762af.tar.bz2
replace max_msg_size with max_data_xfer_size (#541)
The previously specified max_msg_size had one major issue: it implied a (way too small) limit on the size of dirty bitmaps that could be requested by a client, and as a result a hard limit on memory region size. It seemed awkward to attempt to split up an unmap request instead. Instead, let most requests and replies be limited by their "natural" limits; for example, the number of booleans in VFIO_USER_SET_IRQS is limited by MSI-X count. For the requests that solicit or provide data - that is, VFIO_USER_DMA_READ/WRITE and VFIO_USER_REGION_READ/WRITE - we negotiate a new max_data_xfer_size value. These are much easier to split up into separate requests at the client side so should not present an implementation problem. For our server, chunking is implemented in vfu_dma_read/vfu_dma_write(). Signed-off-by: John Levon <john.levon@nutanix.com> Reviewed-by: Swapnil Ingle <swapnil.ingle@nutanix.com> Reviewed-by: Thanos Makatos <thanos.makatos@nutanix.com>
Diffstat (limited to 'include')
-rw-r--r--include/vfio-user.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/include/vfio-user.h b/include/vfio-user.h
index 7be7cf7..43f6877 100644
--- a/include/vfio-user.h
+++ b/include/vfio-user.h
@@ -50,6 +50,8 @@
extern "C" {
#endif
+#define VFIO_USER_DEFAULT_MAX_DATA_XFER_SIZE (1024 * 1024)
+
enum vfio_user_command {
VFIO_USER_VERSION = 1,
VFIO_USER_DMA_MAP = 2,