diff options
author | John Levon <john.levon@nutanix.com> | 2021-06-02 16:08:14 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-06-02 16:08:14 +0100 |
commit | 57684de8240fce4a277301a86a803842338762af (patch) | |
tree | ea1066e2ae4de34bd7b77f9fb7a26af40848b52f /include | |
parent | b8234a75d9ec2c95cb889c0cef27927f34ad9cbc (diff) | |
download | libvfio-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.h | 2 |
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, |