libkrun: Produce a proper Rust library#588
Conversation
|
Still blocked on rust-vmm/linux-loader#223 or rust-vmm/linux-loader#229 and it being included in a new release. |
d-e-s-o
force-pushed
the
topic/rust-lib
branch
4 times, most recently
from
5987285 to
c834676
Compare
|
I had my 🤖 help me put together a PR describing something I hope we can land before introducing the rust api: #593. The main intent is that we not couple the init into the crate and instead have it as an optional sibling crate. |
The existing version specification for the vm-memory dependency is wrong: it includes incompatible versions that, when used, will break the build. 0.18, for example does not build. Neither does 0.17. We cannot go to 0.18, because linux-loader folks are reluctant to update to 0.18. Hence, move the entire workspace to using vm-memory 0.17. Signed-off-by: Daniel Müller <deso@posteo.net>
Doesn't seem as if one of those is going to get merged anytime soon. So we have to stick with vm-memory 0.17. Updated PR accordingly. |
d-e-s-o
force-pushed
the
topic/rust-lib
branch
4 times, most recently
from
8c40869 to
ac1e901
Compare
d-e-s-o
requested review from
MatiasVara,
dorindabassey,
jakecorrenti,
mtjhrc,
slp and
tylerfanelli
as code owners
|
Could somebody help review the change please? |
| for slice in desc.mem.get_slices(desc.addr, desc.len as usize) { | ||
| let mut slice = slice?; | ||
| match input.read_volatile(&mut slice) { | ||
| Ok(0) => { | ||
| *eof = true; | ||
| break; | ||
| } | ||
| }) | ||
| Ok(n) => total += n, |
There was a problem hiding this comment.
Here, going from try_access() to get_slices() changes the read behavior when guest memory is fragmented. The previous code called read() once, and the new code may call it multiple times (once per slice) until WouldBlock. This is probably fine, but worth noting since it's not mentioned in the PR description and should probably be tested with fragmented guest memory.
There was a problem hiding this comment.
@dorindabassey It should be the same in this regard actually, the old code would call it multiple times too - try_access invoked the closure for each slice.
Not sure if there is actually a functional difference here, so far haven't noticed any, but this did look suspicious it might break something.
There was a problem hiding this comment.
Ah thanks for clarifying! But separately, looks like there might be an issue with partial reads within a single slice as per gemini.
There was a problem hiding this comment.
Perhaps it's best if we leave the code as it was for now? I only adjusted it reluctantly because try_access() has been deprecated. But it hasn't been removed yet and as per semver that can only happen with the next minor bump. So I've just #[allow]ed the deprecation now. Let me know what you think.
dorindabassey
left a comment
dorindabassey
left a comment
There was a problem hiding this comment.
code LGTM, just a few comments.
|
/gemini review |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request performs extensive dependency updates across the project, most notably upgrading vm-memory to version 0.17 and pinning several VMM-related crates to specific versions. It also refactors error handling in the microVM builder and updates the virtio console's I/O logic to utilize get_slices. Feedback identifies critical issues in the new console I/O implementation, specifically that it fails to correctly handle partial reads and writes, which could lead to data loss or inefficient buffer utilization.
Produce a proper Rust library to avoid the need for C library
installation as well as binding generation/definition. Basically, we can
now reference the crate via Cargo.toml:
[dependencies]
libkrun = ...
instead of having to rely on constructs like:
#[link(name = "krun")]
extern "C" {
pub fn krun_create_ctx() -> i32;
...
}
Signed-off-by: Daniel Müller <deso@posteo.net>
4 participants
Produce a proper Rust library to avoid the need for C library
installation as well as binding generation/definition. Basically, we can
now reference the crate via
Cargo.toml:instead of having to rely on constructs like:
For a brief discussion of the topic, see #494 (comment)