Opened 13 months ago
#21897 new defect
Testing on various environments needed: SMP boot is much slower than UP boot.
Reported by: | kumaneko | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox-7.0.12 |
Keywords: | Cc: | kumaneko | |
Guest type: | Linux | Host type: | other |
Description
I'm facing a problem that booting a Linux guest on VirtualBox 7.0.12 on Windows 11 likely hangs (or too slow to wait), as explained at https://lkml.kernel.org/r/a1f1ec27-169a-4853-84d0-7d67d62a7741@I-love.SAKURA.ne.jp .
If guest Linux kernels are built with CONFIG_HZ=1000 (kernels used by e.g. Fedora distribution), booting a guest VM with 8 vCPUs likely hangs. If guest Linux kernels are built with CONFIG_HZ=250 (kernels used by e.g. Ubuntu distribution), booting a guest VM with 8 vCPUs unlikely hangs.
Since it is not clear which component (host OS, VirtualBox, or guest Linux kernel) is misbehaving, I need to check whether this problem is reproducible with different host OSes (e.g. Linux) and hypervisors (e.g. QEMU).
Details are explained at https://marc.info/?l=linux-kernel&m=169841977208805 .
Steps to test (if you don't have environments for developing Linux kernels):
(1) Download an installation ISO image file. (e.g. Fedora-Everything-netinst-x86_64-Rawhide-20231018.n.0.iso Fedora-Server-netinst-x86_64-37-1.7.iso Fedora-Everything-netinst-x86_64-34-1.2.iso )
(2) Boot that ISO image, with "nosmp" kernel command line option added and without adding "nosmp" kernel command line option.
(3) Check if booting with "nosmp" kernel command line option added reaches graphical installer much faster than booting without adding "nosmp" kernel command line option.
Tips: Removing "quiet" option from the kernel command line options allows you to show more messages.
Steps to test (if you have environments for developing Linux kernels):
(1) Build one Linux kernel using https://i-love.sakura.ne.jp/tmp/config-6.6-rc7-ok .
(2) Boot the kernel built at (1). The kernel will panic within few seconds unless this problem happens.
(3) Build another Linux kernel, with CONFIG_HZ changed from 250 to 1000.
(4) Boot the kernel build at (3). The kernel will hang up or panic much later if this problem happens.
Tips: Booting these kernels on hypervisors other than VirtualBox or without using VirtualBox is also appreciated, for it is not clear which component (host OS, VirtualBox, or guest Linux kernel) is misbehaving.
Regards.