You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+2-11Lines changed: 2 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -94,22 +94,13 @@ make test
94
94
- VirtIO improvements:
95
95
- Abstract and improve request/response queue from rng
96
96
- Ensure we zero out descriptors after using them so we don't accidentally reuse the buffer
97
-
- Allocate buffers on the fly instead of using static buffers, or have client provide buffer
98
-
- Reuse them if we are reusing a descriptor, or free them.
99
-
- If the VirtIO device always owns the memory it uses, it is easier to reason about alloc/free, ensure buffers are the right size, and ensure provided buffers are physically contiguous
100
-
- Allocation and pointers: avoid manually calling `memory` alloc functions and passing around pointers
101
-
- Have virtqueues "own" their buffers and handle alloc/dealloc. Devices that need to alloc for descriptors, like virtio-blk, can do the same.
102
-
- We can use `Box<T, KERNEL_PHYSICAL_ALLOC>` to ensure we are using physical memory.
97
+
- Improve memory "ownership" ergonomics, ensuring buffers are dropped after use. Maybe abstract into a common layer somehow?
98
+
- Create a physically contiguous heap, or slab allocator, or something for virtio buffer requests so we don't waste an entire page per tiny allocation.
103
99
- Locking: we need to lock writes (I think?), but we should be able to read from the queue without locking. This should be ergonomic. I don't necessarily want to bury a mutex deep in the code.
104
100
- Investigate how Linux or other OS virtio drivers do locking
105
101
- Ensure we don't accidentally reuse descriptors while we are waiting for a response from the device. Don't automatically just wrap around! This is what might require a mutex rather than just atomic integers?
106
102
- I think there is a race condition with the interrupts with the current non-locking mechanism. Ensure that if there are concurrent writes while an interrupt, then an interrupt won't miss a read (e.g. there will at least be a followup interrupt)
107
103
- Remember features we negotiate, and ensure we are accounting for the different features in the logic (especially around notifications)
108
-
- Physical memory allocation
109
-
- Ensure `PhysicalBuffer` allocation and deallocation is safe, and that page and size math is correct (particularly in `drop()`). Make it foolproof.
110
-
- Be explicit about it allocating pages. Don't pretend it is just addresses. Perhaps put page <-> address translation layer in a single spot.
111
-
- In fact, maybe `LockedPhysicalMemoryAllocator` should _not_ implement `Allocator`. If we want a malloc-like behavior on top of contiguous physical memory, we should explicitly use e.g. `LockedHeap` on top of some allocated physical pages (basically an arena).
112
-
- Does `PhysicalBuffer::allocate` need an alignment argument? Does anything ever need more than page alignment?
113
104
- Create `sync` module that has synchronization primitives
114
105
- Wrapper around `spin::Mutex` that also disables interrupts, similar to Linux's `spin_lock_irqsave` (`x86_64::interrupts::without_interrupts` is handy here). Might need our own custom `MutexGuard` wrapper that handles re-enabling interrupts on `drop()`
115
106
- In the future we should disable preemption when spin locks are taken
0 commit comments