Refactor physical pointer API#824
Conversation
420bea6 to
d0c665c
Compare
8b9b1f7 to
3a833f2
Compare
41e36c2 to
a6c1102
Compare
2473ace to
27bb1dd
Compare
24fcce1 to
3dc8650
Compare
24e1d87 to
9b0f0f0
Compare
6dbe423 to
f6d2dc0
Compare
|
@CvvT I think we should take a look at this PR as well. Thanks! |
wdcui
left a comment
There was a problem hiding this comment.
I left some comments below. I'm confident about my review because this PR has a lot of subtlties, so I didn't approve it and asked Weiteng to take a look at it as well.
lschuermann
left a comment
There was a problem hiding this comment.
I want to take a slightly more in-depth pass over lib.rs, but otherwise this looks pretty good to me!
It's hard to judge what this + the other changes in #817 look like. Is it work merging this one into the sanghle/lvbs/vmap_copy branch first, and then doing another thorough pass over the merged result to make sure it's consistent?
Given the comparisons between this infrastructure and DMA, maybe it's worth looking at tock/tock#4702? That PR to Tock addresses two separate but related concerns:
- It prevents the Rust compiler from making incorrect assumptions about the state of memory it can dereference (Rust slices). This is not directly applicable here, as memory is only ever accessed through
asm!()-backed memcpy helpers, so there is no buffer with "shared custody" between Rust and the foreign entity. - It emits the appropriate synchronization instructions (i.e., fences) for when Rust-issued writes need to be made visible to the foreign entity, or when foreign-issued writes need to be made visible to Rust. This may still be missing here.
8f38930 to
456249b
Compare
59f01a7 to
3c7c42f
Compare
3c7c42f to
e81faba
Compare
|
ℹ️ Note: This semver check was run against the 🤖 SemverChecks 🤖 Click for details |
This PR refactors the physical pointer API. --------- Co-authored-by: Sangho Lee <sanghle@microsoft.com>
This PR refactors the physical pointer API.