-
Notifications
You must be signed in to change notification settings - Fork 481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backport support for vhost-vsock-user #1243
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add the config protocol feature bit if the set_config & get_config callbacks are implemented. Signed-off-by: Marc-André Lureau <[email protected]> Message-id: [email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
Create a vhost-user-backend object that holds a connection to a vhost-user backend (or "slave" process) and can be referenced from virtio devices that support it. See later patches for input & gpu usage. Note: a previous iteration of this object made it user-creatable, and allowed managed sub-process spawning, but that has been dropped for now. Signed-off-by: Marc-André Lureau <[email protected]> Message-id: [email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
Add a new memory backend, similar to hostmem-file, except that it doesn't need to create files. It also enforces memory sealing. This backend is mainly useful for sharing the memory with other processes. Note that Linux supports transparent huge-pages of shmem/memfd memory since 4.8. It is relatively easier to set up THP than a dedicate hugepage mount point by using "madvise" in /sys/kernel/mm/transparent_hugepage/shmem_enabled. Since 4.14, memfd allows to set hugetlb requirement explicitly. Pending for merge in 4.16 is memfd sealing support for hugetlb backed memory. Usage: -object memory-backend-memfd,id=mem1,size=1G Signed-off-by: Marc-André Lureau <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Add a new function to initialize a RAM memory region with a file descriptor to be mmap-ed. Signed-off-by: Marc-André Lureau <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
We were checking this against memory region size of host memory backend's mr field to see whether the mr has been inited. This is efficient but less elegant. Let's make a helper for it to avoid confusions, along with some notes. Suggested-by: Peter Maydell <[email protected]> Signed-off-by: Peter Xu <[email protected]> Message-Id: <[email protected]> Reviewed-by: Eduardo Habkost <[email protected]> Signed-off-by: Eduardo Habkost <[email protected]>
Add a function to only create a memfd, without mmap. The function is used in the following memory backend. Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> Signed-off-by: Eduardo Habkost <[email protected]>
Add qemu_ram_alloc_from_fd(), which can be use to allocate ramblock from fd only. Signed-off-by: Marc-André Lureau <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
This will allow callers to silence error report when the call is allowed to failed. Signed-off-by: Marc-André Lureau <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Linux commit 749df87bd7bee5a79cef073f5d032ddb2b211de8 (v4.14-rc1) added a new flag MFD_HUGETLB to memfd_create() that specify the file to be created resides in the hugetlbfs filesystem. This is the generic hugetlbfs filesystem not associated with any specific mount point. hugetlbfs does not support sealing operations in v4.14, therefore specifying MFD_ALLOW_SEALING with MFD_HUGETLB will result in EINVAL. However, I added sealing support in "[PATCH v3 0/9] memfd: add sealing to hugetlb-backed memory" series, queued in -mm tree for v4.16. Signed-off-by: Marc-André Lureau <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Learn to specificy hugetlb size as qemu_memfd_create() argument. Signed-off-by: Marc-André Lureau <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Move file opening part in a seperate function, file_ram_open(). This allows for reuse of file_ram_alloc() with a given fd. Signed-off-by: Marc-André Lureau <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Add the PCI version of vhost-user-vsock Launch QEMU like this: qemu -chardev socket,path=/tmp/vm.vsock,id=chr0 \ -device vhost-user-vsock-pci,chardev=chr0 Signed-off-by: Stefano Garzarella <[email protected]> Message-Id: <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
This patch introduces a vhost-user device for vsock, using the vhost-vsock-common parent class. The vhost-user-vsock device can be used to implement the virtio-vsock device emulation in user-space. Signed-off-by: Stefano Garzarella <[email protected]> Message-Id: <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
This patch prepares the introduction of vhost-user-vsock, moving the common code usable for both vhost-vsock and vhost-user-vsock devices, in the new vhost-vsock-common parent class. While moving the code, fixed checkpatch warnings about block comments. Signed-off-by: Stefano Garzarella <[email protected]> Message-Id: <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
virtio-vsock features, like VIRTIO_VSOCK_F_SEQPACKET, can be handled by vhost-vsock-common parent class. In this way, we can reuse the same code for all virtio-vsock backends (i.e. vhost-vsock, vhost-user-vsock). Let's move `seqpacket` property to vhost-vsock-common class, add vhost_vsock_common_get_features() used by children, and disable `seqpacket` for vhost-user-vsock device for machine types < 6.2. The behavior of vhost-vsock device doesn't change; vhost-user-vsock device now supports `seqpacket` property. Signed-off-by: Stefano Garzarella <[email protected]> Message-Id: <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
This patch prepares the introduction of vhost-user-vsock, moving the common code usable for both vhost-vsock and vhost-user-vsock devices, in the new vhost-vsock-common parent class. While moving the code, fixed checkpatch warnings about block comments. Signed-off-by: Stefano Garzarella <[email protected]> Message-Id: <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> AF: this commit should probably come sooner
Superseded by #1386 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Work in progress