Rob Bradford
Rob Bradford
Our current user focussed documentation has significant gaps as well as being somewhat in inconsistent and style.
- [x] Snapshot/restore `virtio-mem` https://github.com/cloud-hypervisor/cloud-hypervisor/issues/1595 - [x] Snapshot/restore `virtio-balloon` https://github.com/cloud-hypervisor/cloud-hypervisor/issues/1598 - [x] Snapshot/restore `vhost-user` https://github.com/cloud-hypervisor/cloud-hypervisor/issues/1599 - [x] "versioning" https://github.com/cloud-hypervisor/cloud-hypervisor/issues/1600 - [x] Dirty write tracking by the VMM (#2458) - [...
e.g. Checking all access of host memory is done in a safe way (not bypassing `GuestMemory` or `GuestAddress` helper functions Particular areas to focus on - [ ] virtio-block -...
We've been on forked versions too long. We need to either work out how to upstream the serde bits or have an alternative approach that we use inside Cloud Hypervisor.
This will improve our error reporting and we will not need to rely on printing errors with `{:?}` i.e. `#[derive(Debug)`
Look into fuzzing some of our key guest visible code: - [x] QCOW2 implementation - [ ] VIRTIO queues - [ ] virtio-net handling - [x] virtio-block handling External interface...
Add basic support for tracing the boot. The tracing only has overhead if compiled in with the "tracing" feature. - tracing: Add initial basic tracing support - vmm: Add some...
Currently all types of firmware we support can be booted via PVH so we can remove our legacy firmware loading.
A PR was landed that added a new file that didn't have copyright header. A good solution for checking this is reuse - https://github.com/fsfe/reuse-action
Need a transition path away: https://github.com/actions-rs/toolchain/issues/216 This could be a good alternative: https://github.com/actions-rust-lang/setup-rust-toolchain or https://github.com/dtolnay/rust-toolchain