Add multiple migration support for vmcall-vsock
#320
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| log::info!("Set MSK and report status\n"); | ||
| exchange_information.key.clear(); | ||
| remote_information.key.clear(); | ||
|
|
||
| Ok(()) | ||
| } | ||
|
|
||
| fn exchange_info(info: &MigrationInformation) -> Result<ExchangeInformation> { |
Check warning
Code scanning / clippy
associated functions exchange_info, read_msk, and write_msk are never used Warning
| Ok(exchange_info) | ||
| } | ||
|
|
||
| fn read_msk(mig_info: &MigtdMigrationInformation, msk: &mut MigrationSessionKey) -> Result<()> { |
Check warning
Code scanning / clippy
associated functions exchange_info, read_msk, and write_msk are never used Warning
| Ok(()) | ||
| } | ||
|
|
||
| fn write_msk(mig_info: &MigtdMigrationInformation, msk: &MigrationSessionKey) -> Result<()> { |
Check warning
Code scanning / clippy
associated functions exchange_info, read_msk, and write_msk are never used Warning
gaojiaqi7
force-pushed
the
1101/async_vmcall
branch
from
1c68919 to
faf4529
Compare
src/migtd/src/driver/timer.rs
Outdated
| @@ -32,7 +27,7 @@ pub fn schedule_timeout(timeout: u64) -> Option<u64> { | |||
| reset_timer(); | |||
| let cpuid = unsafe { core::arch::x86_64::__cpuid_count(0x15, 0) }; | |||
| let tsc_frequency = cpuid.ecx * (cpuid.ebx / cpuid.eax); | |||
| let timeout = timeout / 1000 * tsc_frequency as u64; | |||
| let timeout = tsc_frequency as u64 * timeout / 1000; | |||
There was a problem hiding this comment.
- timeout function should guarantee to timeout enough time.
A proper way for x / 1000 should be (x + 999) / 1000.
-
Please describe the unit (ms? or us?, or s?)
-
I feel u32 timeout value is enough for
schedule_timeout(timeout: u32) -
Can we give a different name for local variable
timeout, what is difference from input paramtimeout?
There was a problem hiding this comment.
For 1, the purpose of this line of code is to calculate the increase in the Time Stamp Counter (TSC) value over a specified delay period, I think rewrite as tsc_frequency as u64 / 1000 * timeout as u64 is a better way to address the potential overflow.
For 2/3/4, the code/comments has been updated.
| @@ -135,6 +137,50 @@ fn handle_pre_mig() { | |||
| } | |||
| } | |||
|
|
|||
| #[cfg(feature = "async")] | |||
| fn handle_pre_mig() { | |||
There was a problem hiding this comment.
why we need to handle sync and async differently? Why we need a feature?
There was a problem hiding this comment.
The original wait_for_request on Linux blocks the program from reading/writing from virtio vsock/serial until next migration request comes. I suggest to file a new issue to track the async compatiblity on block version wait_for_request.
src/migtd/src/migration/session.rs
Outdated
| @@ -155,7 +162,7 @@ impl MigrationSession { | |||
| Ok(()) | |||
| } | |||
|
|
|||
| pub fn wait_for_request(&mut self) -> Result<()> { | |||
| pub fn wait_for_request(&mut self, block: bool) -> Result<Option<u64>> { | |||
There was a problem hiding this comment.
why we need to support block here? Can we use false for original use case?
There was a problem hiding this comment.
Removed. The async and sync code blocks are merged.
gaojiaqi7
force-pushed
the
1101/async_vmcall
branch
from
faf4529 to
25e18c6
Compare
gaojiaqi7
force-pushed
the
1101/async_vmcall
branch
5 times, most recently
from
95cbeea to
9473f17
Compare
`async_io` and `async_runtime` are introduced to provide async/await support. Signed-off-by: Jiaqi Gao <[email protected]>
Signed-off-by: Jiaqi Gao <[email protected]>
gaojiaqi7
force-pushed
the
1101/async_vmcall
branch
from
9473f17 to
b6a6ab5
Compare
If the block flag of the vsock/serial is not set, transport layer will not wait for the data and return `NotReady` error if the data is not ready. Signed-off-by: Jiaqi Gao <[email protected]>
To avoid potential integer overflow. Signed-off-by: Jiaqi Gao <[email protected]>
A system tick is maintained to support timeout future. Signed-off-by: Jiaqi Gao <[email protected]>
Signed-off-by: Jiaqi Gao <[email protected]>
gaojiaqi7
force-pushed
the
1101/async_vmcall
branch
from
b6a6ab5 to
e922532
Compare
No description provided.