What does the boot time means in the QEMU? - qemu

Question

When i boot linux on the qemu, there is the time stamp in the boot log as follows,
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.10.0 (zlp#lab302i-ES) (gcc version 4.9.3 20150626 (Red Hat 4.9.3-2) (GCC) ) #33 PREEMPT Mon Dec 2 14:39:51 CST 2019
[ 0.000000] Config serial console: console=ttyS0,38400n8r
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU revision is: 00018900 (MIPS 5KE)
[ 0.000000] FPU revision is: 00738900
[ 0.000000] Software DMA cache coherency enabled
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 0000000000001000 # 0000000000000000 (reserved)
[ 0.000000] memory: 00000000000ef000 # 0000000000001000 (ROM data)
[ 0.000000] memory: 000000000071c000 # 00000000000f0000 (reserved)
[ 0.000000] memory: 000000000f7f4000 # 000000000080c000 (usable)
[ 0.000000] Wasting 28840 bytes for tracking 515 unused pages
[ 0.000000] Reserving 0MB of memory at 0MB for crashkernel
[ 0.000000] Kernel command line: rd_start=0xffffffff80810000 rd_size=16642887 root=/dev/ram0 nokaslr console=ttyS0,38400n8r
[ 0.000000] PID hash table entries: 1024 (order: -1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 4, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)
[ 0.000000] Cache parity protection disabled
[ 0.000000] allocated 262128 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[ 0.000000] Memory: 252272k/253904k available (4743k kernel code, 1632k reserved, 1899k data, 320k init, 0k highmem)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] NR_IRQS:256
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] Calibrating delay loop... 1145.06 BogoMIPS (lpj=2236416)
[ 0.074218] pid_max: default: 32768 minimum: 301
[ 0.074218] Security Framework initialized
[ 0.074218] AppArmor: AppArmor disabled by boot time parameter
[ 0.074218] Mount-cache hash table entries: 1024
[ 0.078125] Initializing cgroup subsys memory
[ 0.078125] Initializing cgroup subsys devices
[ 0.078125] Initializing cgroup subsys freezer
[ 0.078125] Initializing cgroup subsys blkio
[ 0.078125] Initializing cgroup subsys perf_event
[ 0.089843] devtmpfs: initialized
[ 0.093750] NET: Registered protocol family 16
...
In a real board, the time stamp means the boot time. Now in QEMU, what does it mean?
Is it the real time consumed by the QEMU to run the linux boot code? Is it accurate?
It seems that this time stamp is shorter than the real board. Is it because of the QEMU don't have the real I/O operations?
Can i evaluate the real time consumed or the time proportion of each part of the kernel boot of the real board by the QEMU boot log?

Answer 1

In QEMU it means guest time as perceived by linux. How it relates to the host time depends on what emulated clock device is used for time measurement.
Guest linux kernel typically reads some register of that emulated clock device and converts it into its system time using clock frequency that is configured somewhere or is measured by the kernel.
Emulated clock devices can expose clock based on one of the QEMU internal clock types, typically QEMU_CLOCK_VIRTUAL, but they're not limited to it.
When QEMU_CLOCK_VIRTUAL is used the way it ticks depends on whether QEMU is started with -icount switch or not. When -icount is not used QEMU_CLOCK_VIRTUAL ticks synchronously with the host clock when guest CPU is running. When -icount is used it specifies how many nanoseconds of QEMU_CLOCK_VIRTUAL time each executed guest instruction takes. QEMU_CLOCK_VIRTUAL then ticks proportionally to the number of guest instructions executed by the guest CPU. It also ticks when guest CPU does not execute guest instructions (e.g. is halted waiting for an interrupt) but I don't know the details.
Is it the real time consumed by the QEMU to run the linux boot code?
Is it accurate?
It has some relation to the time taken by the QEMU to run the linux boot code, but it's not precisely it and it depends on the guest kernel configuration, emulated hardware and the way QEMU is started.