File I/O DMA region access mode#842
Conversation
This adds an enum to convey how a DMA region is to be accessed. Previously, this was implicit in the presence of a file descriptor in the DMA region tracking information. With this change, a new file I/O access mode is added that designates accesses should happen via file I/O syscalls, such as `pread()`/`pwrite()`. This is useful for file descriptors that don't support `mmap()`, such as `/proc/<pid>/mem`. The access mode to be used is determined from new flag bits in the VFIO_USER_DMA_MAP message, and the message handler makes sure the passed flags and file descriptor presence are consistent. Existing code is updated to use the access mode in conditionals rather than testing file descriptor presence. Signed-off-by: Mattias Nissler <mnissler@meta.com>
When performing DMA from/to a caller-supplied buffer via `vfu_sgl_write` and `vfu_sgl_read`, respectively, we can use file descriptor based access modes as configured for the region, rather than servicing the DMA operation via IPC unconditionally. Signed-off-by: Mattias Nissler <mnissler@meta.com>
jlevon
left a comment
jlevon
left a comment
There was a problem hiding this comment.
Not sure I'm quite clear on the use case - when would I be sharing something like /proc files with the server?
| return ERROR_INT(EPERM); | ||
| } | ||
|
|
||
| if (sg->region->access_mode == REGION_ACCESS_MODE_MMAP) { |
There was a problem hiding this comment.
hmm, there may be good reasons to want the client to service dma read/write even in the case of MODE_FILE_IO or MODE_MMAP. I wonder if we want a flags param for vfu_dma/read_write() so users can request this if needed?
There was a problem hiding this comment.
That thought crossed my mind as well. Can you think of any plausible reasons though? If the client did provide a file descriptor at registration time, it seems only fair that we use it :-D
I'll be happy to add parameter (or make separate functions) though if you think that's the best way forward.
| uint32_t argsz; | ||
| #define VFIO_USER_F_DMA_REGION_READ (1 << 0) | ||
| #define VFIO_USER_F_DMA_REGION_WRITE (1 << 1) | ||
| #define VFIO_USER_F_DMA_REGION_MMAP (1 << 2) |
There was a problem hiding this comment.
this will need a qemu update to the protocol definition please, as well as ideally updating the qemu headers.
There was a problem hiding this comment.
Yes, I'll be happy to send a patch for that, but wanted to align on the overall proposal here first.
This is for a case where a non-VMM client wants to expose buffers to the server, and it isn't feasible in practice to change all memory allocation code paths in the client to use |
2 participants
This PR adds a new mode to perform DMA operations using file I/O system calls. This is useful in cases where the client can supply a file descriptor, but the file descriptor doesn't support
mmap(). This is the case for/proc/<pid>/memfor example, which can be used to give the server access to the client's address space.