Boot time is broken while running OSv in Docker container

[costinsin]

I have recently tried to run OSv inside a Docker container and I have noticed that the boot time printed is always 0.00ms.

This bug can be replicated by building any docker image that builds an OSv image using ./scripts/build and runs it using ./scripts/run.py.

> docker run osv
OSv v0.57.0-11-g65554bcc
eth0: 192.168.122.15
Booted up in 0.00 ms

Minimal Dockerfile

FROM ubuntu:latest

RUN apt-get -y update && apt-get -y install git python3
RUN git clone --recurse-submodules https://github.com/cloudius-systems/osv /osv
WORKDIR /osv
RUN python3 ./scripts/setup.py
RUN ./scripts/manifest_from_host.sh -w ls && ./scripts/build --append-manifest

CMD ["/osv/scripts/run.py"]

[wkozaczuk]

Hi,

The boot time 0.00ms typically indicates that OSv is running on QEMU without hardware acceleration (aka KVM) enabled which causes OSv to use hpet clock which does not provide the functionality required to implement the (processor_to_nano)[https://github.com/cloudius-systems/osv/blob/master/drivers/clock.hh#L101] function used by the boot chart.

I believe you need to run docker with the option --privileged - please see this docker file for an example.

I assume your host CPU can provide direct or nested hardware acceleration.

Please let me know if it helps.

[costinsin]

Thank you for clearing this up for me! I used --device=/dev/kvm to solve this issue because --privileged might be too powerful for my use case.

[wkozaczuk]

I was not aware of the --device=/dev/kvm option. This definitely seems like a better/more secure way to run a Docker container to allow OSv to use KVM.

[nyh]

The boot time 0.00ms typically indicates that OSv is running on QEMU without hardware acceleration (aka KVM) enabled which causes OSv to use hpet clock which does not provide the functionality required to implement the (processor_to_nano)[https://github.com/cloudius-systems/osv/blob/master/drivers/clock.hh#L101] function used by the boot chart.

Can't we use the HPET clock to provide at least an approximation of the boot time?

But even before that - I see boot_time_chart::print_chart() avoids printing the boot chart when the clock can't do it. So I think boot_time_chart::print_total_time() should do the same - if all it can report is a fake 0ms, it's better not to report anything.