-
Notifications
You must be signed in to change notification settings - Fork 70
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
vhost_user: Add support for SHMEM_MAP/UNMAP backend requests #251
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Author and SoB are different, can you fix it, or add @aesteve-rh SoB if he is a co-author.
Please check also the coverage and add a line in the changelog.
Extract creating a backend and a frontend from a socketpair to a utility function. Signed-off-by: Matej Hrica <mhrica@redhat.com>
80c4bf1
to
630cd66
Compare
I have addressed the feedback, you can take another look. Also, should I add some comment that this feature is not really "stable"? Or will this PR have to wait until it gets merged in QEMU? |
The coverage was too low, so I wanted to add a test for the default impl of the frontend request handlers, but I also added coverage for all the methods, since that seemed quite trivial. This has increased the coverage too much, so I had to increase the coverage config value. |
The code LGTM, but before merging this PR, I'd like to wait at least the spec merged in QEMU. WDYT? |
I understand the concern. I'm talking to @aesteve-rh to see if we can figure something out |
cd80826
to
5f05fec
Compare
Add request defintions and methods for using the new SHMEM_MAP/UNMAP backend requests. Note that at the time of writing this, these requests are part of this RFC in QEMU: https://mail.gnu.org/archive/html/qemu-devel/2024-06/msg05736.html Co-authored-by: Albert Esteve <aesteve@redhat.com> Co-authored-by: Matej Hrica <mhrica@redhat.com> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Matej Hrica <mhrica@redhat.com>
Add tests to assert return values (and existence) of default implemenation of VhostUserFrontendReqHandler and VhostUserFrontendReqHandlerMut trait methods. Signed-off-by: Matej Hrica <mhrica@redhat.com>
Signed-off-by: Matej Hrica <mhrica@redhat.com>
(self.flags & !VhostUserMMapFlags::all().bits()) == 0 | ||
&& self.fd_offset.checked_add(self.len).is_some() | ||
&& self.shm_offset.checked_add(self.len).is_some() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you want to add more checks relevant to the struct? e.g a check based on valid values for shmid
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From virtio spec:
A device may have multiple shared memory regions associated with it. Each region has a shmid to identify it, the meaning of which is device-specific.
According to the virtio
(not vhost) spec the valid values of shmid
are dependent on the device type (And probably the advertised device features...), so I don't think you could check it here generally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, fair enough for shmid
, you can leave it as it is.
|
||
fn shmem_map(&mut self, req: &VhostUserMMap, _fd: &dyn AsRawFd) -> HandlerResult<u64> { | ||
assert_eq!({ req.shmid }, 0); | ||
Ok(!self.shmem_mappings.insert((req.shm_offset, req.len)) as u64) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it's better to remove the negation (!) and use a direct check to return meaningful values. e.g if self.shmem_mappings.insert(req.shm_offset, req.len) { Ok(1) } else { Ok(0) }
and why the double braces? missing &?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By braces do you mean ( )
or { }
? The (req.shm_offset, req.len)
is a tuple.
In regards to the negation with cast instead of explicit if
, I considered to write it like you did, I mainly wrote it like this, because it is symmetric with the existing shared_object_add
, shared_object_remove
above:
fn shared_object_add(&mut self, uuid: &VhostUserSharedMsg) -> HandlerResult<u64> {
Ok(!self.shared_objects.insert(uuid.uuid) as u64)
}
fn shared_object_remove(&mut self, uuid: &VhostUserSharedMsg) -> HandlerResult<u64> {
Ok(!self.shared_objects.remove(&uuid.uuid) as u64)
}
I am not sure if I should change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The (req.shm_offset, req.len) is a tuple.
ah right!
because it is symmetric with the existing shared_object_add, shared_object_remove above:
doesn't necessarily mean it's the correct approach.
|
||
fn shmem_unmap(&mut self, req: &VhostUserMMap) -> HandlerResult<u64> { | ||
assert_eq!({ req.shmid }, 0); | ||
Ok(!self.shmem_mappings.remove(&(req.shm_offset, req.len)) as u64) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
are you talking about the vhost-user specification https://qemu-project.gitlab.io/qemu/interop/vhost-user.html#message-specification? |
@dorindabassey yep
yeah, if it's possible, I'd go in that direction. |
Summary of the PR
This PR adds support for backend requests
SHMEM_MAP
andSHMEM_UNMAP
.This allows the device to memory map a file descriptor into a
Shared Memory Region
.The
SHMEM_MAP
andSHMEM_UNMAP
are part of this QEMU RFC:I don't anticipate these specific requests to change much, the discussion for this RFC is mainly about a situation where one device is accessing shared memory mapped by another device.
These requests are required for implementing blob resource support in vhost-user-gpu.
The current gpu PR, doesn't implement blob resources and as such doesn't require this, but I am working on creating another PR with blob resource support.
This is based on a commit by Albert Esteve aesteve@redhat.com in his branch/fork.
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:
git commit -s
), and the commit message has max 60 characters for thesummary and max 75 characters for each description line.
test.
Release" section of CHANGELOG.md (if no such section exists, please create one).
unsafe
code is properly documented.