user_driver: use ramfs to allocate DMA buffers #537
Closed
+47
−15
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
When allocating DMA buffers for noiommu VFIO devices, we need to ensure that the kernel will not move the buffers in physical memory. In some cases, we achieve that by managing the memory entirely in user mode. In others, we allocate memory from the kernel on demand and then lock it with `mlock`. The `mlock` approach apparently does not always work--since we are locking pages allocated for an anonymous mapping, the kernel is still free to _move_ the allocation between physical pages. `mlock`'s only guarantee seems to be that the kernel will not swap the page out to the swap file (which doesn't exist in the OpenHCL environment anyway). It looks like pages are indeed being moved with the ARM64 kernel for a reason that is not yet completely understood. To fix this, switch to using a temporary file in ramfs instead of using an anonymous mapping. This should guarantee the allocation does not move between physical pages since ramfs pages are allocated as unmovable in the kernel. Also, update the init process to mount ramfs. This has no resource usage effect by itself--ramfs allocates memory only as required.
yupavlen-ms
reviewed
Dec 18, 2024
| // SAFETY: No file descriptor or address is being passed. | ||
| // The result is being validated. | ||
| let addr = unsafe { | ||
| libc::mmap( | ||
| std::ptr::null_mut(), | ||
| len, | ||
| libc::PROT_READ | libc::PROT_WRITE, | ||
| libc::MAP_PRIVATE | libc::MAP_ANONYMOUS | libc::MAP_LOCKED, | ||
| -1, | ||
| libc::MAP_SHARED | libc::MAP_LOCKED, |
There was a problem hiding this comment.
MAP_ANONYMOUS should zeroinit pages according to the documentation but MAP_SHARED should not. LockMem::new should zeroinit pages anyway, do we know if all cases are covered? (assuming the doc is correct about this).
|
Unfortunately, testing shows that this doesn't seem to resolve the underlying issue. |
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.
When allocating DMA buffers for noiommu VFIO devices, we need to ensure that the kernel will not move the buffers in physical memory. In some cases, we achieve that by managing the memory entirely in user mode. In others, we allocate memory from the kernel on demand and then lock it with
mlock.The
mlockapproach apparently does not always work--since we are locking pages allocated for an anonymous mapping, the kernel is still free to move the allocation between physical pages.mlock's only guarantee seems to be that the kernel will not swap the page out to the swap file (which doesn't exist in the OpenHCL environment anyway). It looks like pages are indeed being moved with the ARM64 kernel for a reason that is not yet completely understood.To fix this, switch to using a temporary file in ramfs instead of using an anonymous mapping. This should guarantee the allocation does not move between physical pages since ramfs pages are allocated as immovable in the kernel.
Also, update the init process to mount ramfs. This has no resource usage effect by itself--ramfs allocates memory only as required.