Running uhyve in a Linux VirtualBox VM (with nested virtualization enabled) panics in detect_freq_from_cpuid

[ColinFinck]

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

[mkroening]

This is probably one of these:

https://github.com/hermitcore/uhyve/blob/70b9425fcc556c2854bd9a5317794631f1b0bb6a/src/arch/x86_64/mod.rs#L43-L44

[charlottestinson]

Hello, this is the same team from UT! We are interested in working on this issue as well. Would that be alright?

[jounathaen]

No need to ask, PRs are always welcome

[n0toose]

I believe that this issue can be closed because of #688, #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.