uhyve
uhyve copied to clipboard
hermit-os
A specialized hypervisor for Hermit.
A panic in the hypercall causes uhyve to hang indefinitely, as only the specific CPU thread will panic, and all other threads are still waiting for the barrier in https://github.com/hermit-os/uhyve/blob/360b613ee7498d0a1b651399f27fb6f5460497ad/src/linux/mod.rs#L137...
We need a HW-agnostic variant of `PhysAddr`. This breaks AArch64, but that's fine for now, I guess. I'm already working on a unified crate for `PhysAddr` and `VirtAddr` for all...
This is the _vm_memory_ crate part of https://github.com/hermit-os/uhyve/pull/643 I'm myself not quite sure if this makes sense, but I wanted to separate it from the PR above.
As discussed here https://github.com/hermit-os/uhyve/pull/527/files#r1478416022, we should find a method to safely access guest memory mutably (`&GuestMemory -> &mut [MaybeUninit]`). It might make sense to encode exclusive access guaranteed by the...
When I run `cargo test gdb` on the main branch and add a print to the `read_addrs` function, https://github.com/hermit-os/uhyve/blob/dc6b01e1294f610af309be44cbdb91c9e623b944/src/linux/gdb/mod.rs#L121 I get the following reads: ``` [...] >>> reading start_addr 0x59d478...
Supersedes https://github.com/hermitcore/uhyve/pull/491 (Uhye-Interface was merged in the meantime, which made this PR requiring a rework)
Currently, VCPUs are not `Send` because they hold an `Arc` to a `VirtioNetPciDevice` that somehow internally uses pointers and is thus by default not `Send`. I have the feeling, that...