uhyve
uhyve copied to clipboard
Running uhyve in a Linux VirtualBox VM (with nested virtualization enabled) panics in `detect_freq_from_cpuid`
During the unikernel meet-up, I just tried uhyve in a Linux VirtualBox VM (with nested virtualization enabled) and I get
cfinck@kubuntuvm:~/unikernel-meetup/hands-on-session/hello-hermit$ RUST_BACKTRACE=1 uhyve -v target/x86_64-unknown-hermit/debug/hello-hermit
thread 'main' panicked at 'attempt to divide by zero', /home/cfinck/.cargo/registry/src/index.crates.io-6f17d22bba15001f/uhyve-0.2.2/src/arch/x86_64/mod.rs:47:25
stack backtrace:
0: rust_begin_unwind
at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:578:5
1: core::panicking::panic_fmt
at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:67:14
2: core::panicking::panic
at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:117:5
3: uhyvelib::arch::x86_64::detect_freq_from_cpuid
4: uhyvelib::vm::detect_cpu_freq
5: uhyvelib::linux::<impl uhyvelib::linux::uhyve::Uhyve>::run
6: uhyve::run_uhyve
7: uhyve::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
CC @mkroening
This is probably one of these:
https://github.com/hermitcore/uhyve/blob/70b9425fcc556c2854bd9a5317794631f1b0bb6a/src/arch/x86_64/mod.rs#L43-L44
Hello, this is the same team from UT! We are interested in working on this issue as well. Would that be alright?
No need to ask, PRs are always welcome
I believe that this issue can be closed because of https://github.com/hermit-os/uhyve/pull/688, https://github.com/hermit-os/uhyve/pull/701.
I tested it myself just to be sure. The kernel still panics later down the line, but adding detect_cpu_freq()
with the detect_freq_from_sysinfo()
call removed does not immediately panic, meaning that detect_freq_from_cpuid
is sound and that the case is being handled properly.