[Bug]: macOS Intel host (driverless/NEM): idle Linux guest causes ~300% host CPU – halt method1 fallback spins in timer loop

Đang mở
  • Có gì không ổn?
#946 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 6 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
42/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c, linux, macos
Lĩnh vực
operating-systems, performance

Hướng nghiên cứu

Start by reading the attached VBoxHeadless sample and baseline log, especially the driverless/NEM fallback to halt method1 and stacks in TMR3TimerQueuesDo. Then trace the VMM halt loop and timer polling paths that those traces identify; reproduce with an idle four-vCPU guest and compare halt statistics with two vCPUs. Done means the EMTs block effectively and idle host CPU use drops while guest behavior remains correct.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug
Version

7.2.22

Host OS Type

macOS

Host OS name + version

macOS 15 Sequoia (Darwin 24.6.0) via OpenCore Legacy Patcher 2.5.1, Mac mini Late 2014 (Macmini7,1), Intel Core i5-4260U (Haswell, 2 cores / 4 threads)

Host Architecture

x86

Guest OS Type

Linux

Guest Architecture

x86

Guest OS name + version

Home Assistant OS 18.4 (x86_64), 2 GB RAM

Component

VMM

What happened?

An almost idle guest causes sustained high host CPU usage in VBoxHeadless.

  • Guest reports ~6% CPU (4 vCPUs).
  • Host ps -o %cpu for VBoxHeadless: avg ~310% over 21 samples (range 216–334%).
  • Host load average ~4.0 on a 2-core / 4-thread host.

VM config: 4 vCPUs, paravirtprovider=hyperv, hwvirtex=on, nestedpaging=on,
2x NIC bridged (no NAT), xHCI with one USB passthrough device (CP210x),
graphicscontroller=vboxsvga, vram=16, audio=none, VRDE off, started headless
via VBoxManage startvm --type headless.

vbox-ha-baseline-4cpu.log shows the VM runs in driverless/NEM mode and falls back to halt method1:

HM: HMR3Init: Attempting fall back to NEM: Driverless mode
VMEmt: Halt method global1 (5) not available in driverless mode, using method1 (4) instead
TM: cTSCTicksPerSecond=... enmTSCMode=4 (NativeApi)

Halt statistics (VBoxManage debugvm ... statistics --pattern "*Halt*", ~26 h uptime):

vCPU cNsHalted Halt/Block cTicks Halt/Timers cPeriods Halt/Timers cTicks
0 56,915 s 1,886 s 248.8e9 13,653 s
1 81,044 s 12,424 s 282.5e9 16,537 s
2 81,134 s 7,049 s 308.5e9 17,813 s
3 n/a 12,850 s 50.0e9 46,848 s

The EMTs actually block for only 3–15% of the halted time. vCPU1 runs the
timer queues ~30,000 times per halt episode. Halt/Timers alone accounts for
~95,000 s CPU over ~26 h (~1 core continuously).

Timers are not the cause: info timers shows APIC timers with HzHint
11/11/4 Hz, /TM/MaxHzHint = 0, PIT and RTC periodic stopped (tickless guest).

Virtual sync catch-up is not active: only 4 catch-up events, all within
the first 28 minutes after power-on (two "Giving up catch-up attempt at a
~60 s lag" during boot). No catch-up afterwards; /TM/VirtualSync/CurrentOffset
≈ GivenUp + 0.31 s.

macOS sample of VBoxHeadless (5 s, top of stack):

mach_absolute_time                           3621
VBoxVMM.dylib +0x271cb7..+0x271de8 (unsym.)  ~1500  (address range just below TMTimerLock)
hv_vmx_vcpu_run_until                         950   (≈ actual guest work)
PDMCritSectEnter/Leave                        692
TMR3TimerQueuesDo                             352
VMMGetCpu                                     231
RTTimeSystemNanoTS / RTTimeNanoTS             316

So ~0.3 cores of guest execution and ~2.4 cores of host overhead, mostly
time queries and timer polling inside the halt loop.

Workaround: reducing to 2 vCPUs drops idle host CPU to ~13–60%.

Note: the host runs macOS 15 on officially unsupported hardware via OpenCore
Legacy Patcher. The driverless/method1 fallback itself is not OCLP-specific
(it applies to all macOS hosts since 7.0), but I cannot rule out an influence.

Log files:
vbox-sample.txt
vbox-ha-baseline-4cpu.log

How can we reproduce this?
  1. Intel Mac host (Haswell, 2C/4T), macOS 15 via OCLP, VirtualBox 7.2.22 (driverless/NEM mode).
  2. Import HAOS 18.4 (generic x86-64 VDI), 4 vCPUs (= all host threads), bridged networking.
  3. Start headless, let the guest idle.
  4. Compare guest CPU with host ps -o %cpu -p $(pgrep -x VBoxHeadless).
  5. Check halt stats and sample <pid> 5.

Not a duplicate of #806:
#806 shows a similar symptom (Intel Mac host, idle Linux guest, high
VBoxHeadless CPU), but it is a different issue:

  • #806 is caused by NAT. The workaround there is to remove NAT, and it was
    reported fixed by 7.2.14.
  • This VM has no NAT at all. Both NICs are bridged, and the issue still
    occurs on 7.2.22.
  • Here the cause is visible in the VMM itself: the log shows the fallback to
    halt method1 in driverless mode, the EMTs block for only 3–15% of the halted
    time (Halt/Block vs. cNsHalted), and the sample output shows them spinning
    in TMR3TimerQueuesDo / mach_absolute_time.
  • The workaround is also different: reducing the vCPU count (4 → 2) drops idle
    host CPU from ~310% to ~13–60%. The network configuration was not changed.
Did you upload all of your necessary log files, screenshots, etc.?
  • Yes, I've uploaded all pertinent files to this issue.
Ngôn ngữ chính
C
Star
1.4k
Fork
219
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của VirtualBox/virtualbox

Tất cả issue của VirtualBox/virtualbox

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.