Opened 7 years ago
Last modified 6 years ago
#17898 new defect
Can Not Assign More Than 8 Processors to Windows 10 Guest
Reported by: | Jagdpanther | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 5.2.16 |
Keywords: | Cc: | ||
Guest type: | Windows | Host type: | Linux |
Description
I just built a new Linux (Gentoo) system based on a SuperMicro mainboard, C9X299-PG300, and an Intel i9-7940X (14-core, 28 thread) CPU. I copied over my Windows 10 VirtualBox guest VM from the old system (Intel i7 8-core) to the new system. The Virtual Box guest boots without issue using the old settings (8-processors). However, if I shut down the VM and change the settings to a higher processor count (I have tried 12 and 14 cores), the VM does not progress very far into its boot: I see a blue background and the windows icon. None of the VirtualBox activity icons at the bottom of the Guest window are active: all dark. That is it. There is one Virtual Box process that continues to run at 100% cpu usage until I kill the VM. In the VirtualBox log the relevant part is:
00:00:03.569172 VMMDev: Guest Log: BIOS: Boot : bseqnr=1, bootseq=0032 00:00:03.570686 VMMDev: Guest Log: BIOS: Booting from Hard Disk... 00:00:03.872720 Display::handleDisplayResize: uScreenId=0 pvVRAM=00007f2f74000000 w=1024 h=768 bpp=24 cbLine=0xC00 flags=0x0 00:00:03.872802 GUI: UIFrameBufferPrivate::NotifyChange: Screen=0, Origin=0x0, Size=1024x768, Sending to async-handler 00:00:03.872885 GUI: UIMachineView::sltHandleNotifyChange: Screen=0, Size=1024x768 00:00:03.872897 GUI: UIFrameBufferPrivate::handleNotifyChange: Size=1024x768 00:00:03.872908 GUI: UIFrameBufferPrivate::performResize: Size=1024x768, Directly using source bitmap content 00:00:04.610473 GIM: HyperV: Guest OS reported ID 0x1040a0000271b 00:00:04.610490 GIM: HyperV: Open-source=false Vendor=0x1 OS=0x4 (Windows NT or derivative) Major=10 Minor=0 ServicePack=0 Build=10011 00:00:04.610506 GIM: HyperV: Enabled hypercall page at 0x000000000020f000 00:00:04.610778 GIM: HyperV: Unknown/invalid hypercall opcode 0x8001 (32769) 00:00:04.610792 GIM: HyperV: Enabled TSC page at 0x000000000000c000 - u64TscScale=0xd3add100000000 u64TscKHz=0x2f3dc9 (3 096 009) Seq=1 00:00:04.610982 TM: Switching TSC mode from 'VirtTscEmulated' to 'RealTscOffset' 00:00:04.611068 GIM0: HyperV: Enabled APIC-assist page at 0x000000000000d000 00:00:04.614818 APIC0: Attempt to read reserved/unknown MSR (0x80e) -> #GP(0) 00:00:04.614825 IEM: rdmsr(0x80e) -> #GP(0) 00:00:04.614859 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e P1=0xffffffffc0000096 P2=0xfffff80360406fd9 P3=0x0 P4=0x0 00:05:36.462561 GUI: Request to close active machine-window.
The "HyperV: Guest indicates a fatal condition!" does not look good.
Change History (8)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Using VirtualBox-5.2.22 and Microsoft provided file Win10_1803_English_x64_April_2018.iso I attempted to create a new VM with 16GB RAM, a 60GB virtual hard drive and 14 cores. As in the original bug report I see a blue background and the windows icon when booting from the .iso file, but no additional progress towards the install.
comment:3 by , 7 years ago
Partial logs are not useful. Attach a full VM log. Set the Paravirtualization Interface from Default to None, see if that changes anything. Try lowering the CPU core count even more ( to 9, for example).
comment:4 by , 7 years ago
Setting paravirtualizaton for the Windows 10 guest from Default to None and minimal both work with "14 processors". Setting paravirtualization to Hyper-V, which according to the manual I should for Windows 10 guests, gives the freeze. I have not tested yet to see what difference Minimal vs None gives. I also have not yet tested the performance difference between an 8-core, Hyper-V paravirtualization Win 10 Guest VS a 14-core, minimal paravirtualization Win 10 Guest.
comment:5 by , 6 years ago
As mentioned in my last post, using paravirtualization minimal or paravirtualization none both "work". However, from the following test results where I am processing 5 images (recipe output from Phase One's Capture One Pro 12 in my Windows 10 VM -- uses all available processors) using 8 processors with Hyper-V paravirtualization is significantly faster than using 14 processors with none or minimal paravirtualizaton:
8 processors Hyper-V Paravirtualization 5-image: 45 Seconds 14 processors Minimal Paravirtualization 5-image: 97 Seconds 14 processors None Paravirtualization 5-image: 107 Seconds
comment:6 by , 6 years ago
Setting the paravirtulization to kvm allows you to use the current 32 core limit. However, if you do so, the system will be orders of magnitude slower than 8 core-hyper-v and not even close to native 32 cores.
It does not help if you use Windows 10 x64 for workstations with extended xeon support.
I've been using the 'Win10_1809Oct_EnglishInternational_x64.iso'
comment:7 by , 6 years ago
Using VirtualBox-6.0 I can successfully launch Windows 10 guest (Linux host) with 14 core processor count hyper-v paravirtulization. My quick performance test (same as above) gives the same time as 8 processor hyper-v paravirtulizaton.
comment:8 by , 6 years ago
Related discussion in the forums: https://forums.virtualbox.org/viewtopic.php?f=2&t=87445
This same issue occurs on VirtualBox-5.2.22