SynthCPU: Guest BSOD trying to install Windows 7

[Anton]

Guest - Windows 7 x64 bit Professional Retail. Host system - Debian Linux 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11 UTC 2011 x86_64 GNU/Linux

Windows installer failed with blue screen after "Windows is loading files...", before a splashscreen with error 0xc0000005D (0x000...). Fixed when i was turned --synthcpu off.

[Anton]

Log

[Anton]

VM config

[Frank Mehnert]

Still relevant with VBox 4.1.6? If so, does changing the chipset type from ICH9 to PIIX3 change anything?

[Frank Mehnert]

No response, closing.

[Joel Low]

Hi, sorry for reopening this ticket. I can reproduce this on 4.1.12. Apparently the synthetic CPU does not expose amd64 support to the guest OS, thus Windows BSODs.

Changing to PIIX3 does not resolve the problem (as expected)

[Joel Low]

Sorry, I forgot to also mention that I'm running on a Windows 7 x64 Host. I'll attach the log next.

[Joel Low]

Log from Windows 7 x64 Host and Windows 7 x64 guest with synthcpu on

[Klaus Espenlaub]

To me the real bug seems to be that this is not marked as "experimental", i.e. a documentation issue. Will be done in one of the next releases, but not worth keeping this ticket open.

The rest appears to be a user error - if you enable SynthCPU you have to specify precisely what cpuid values the synthetic CPU should report. If you don't do that all features will be turned off, and that means the guest CPU reports no 64bit support.

[Joel Low]

Thanks for the input. This fact should probably be documented - the documentation makes it sound like synthcpu doesn't require any other config options.

But if you are saying this is an experimental option then probably it shouldn't be documented at all?

[Joel Low]

And as an afternote, I've set the CPUID values for my virtual machine (identical to my host, as per vboxmanage list hostcpuids) and the virtual machine still does not boot. Perhaps this should be a new ticket? Or am I using the feature wrongly?

[Klaus Espenlaub]

If we don't document experimental options at all then they don't have a chance of getting out of this state.

BTW, VBox.log contains a quite detailed dump of what cpuid features the host has and what the guest gets. Maybe that gives a clue. Does 32bit Windows work?

I faintly remember that in the days when this feature was implemented no one could make it work, simply because Windows refuses to boot on CPUs which are not from the usual vendors. Since then no one in our team has touched it.

[Joel Low]

Yes, a synthetic CPU can install and boot Windows Vista x86 and Windows 7 x86, even without explicitly setting CPUID values. Hence I was a little surprised at the asymmetry between x86 and x64.

I'll go look at Vbox.log and update this ticket.

[Joel Low]

Fresh log for attempt to boot x64 guest with synthetic CPU

[Joel Low]

I've just added a new log. Seems like even though I've set the CPUID values using vboxmanage modifyvm (and the .vbox file has it correct), VirtualBox isn't exposing the correct CPUID values to the guest.

I however note on line 986 that Long mode seems to have been enabled, but somehow the guest isn't seeing it (probably because of the wrong CPUID returns?)

[Joel Low]

If you're wondering what CPUID values I've set, they are (excerpt from the .vbox)

        <CpuIdTree>
          <CpuIdLeaf id="0" eax="13" ebx="1970169159" ecx="1818588270" edx="1231384169"/>
          <CpuIdLeaf id="1" eax="132823" ebx="102762496" ecx="532603839" edx="3219913727"/>
          <CpuIdLeaf id="2" eax="1979931137" ebx="15774463" ecx="0" edx="13238272"/>
          <CpuIdLeaf id="3" eax="0" ebx="0" ecx="0" edx="0"/>
          <CpuIdLeaf id="4" eax="0" ebx="0" ecx="0" edx="0"/>
          <CpuIdLeaf id="5" eax="64" ebx="64" ecx="3" edx="135456"/>
          <CpuIdLeaf id="6" eax="119" ebx="2" ecx="1" edx="0"/>
          <CpuIdLeaf id="7" eax="0" ebx="0" ecx="0" edx="0"/>
          <CpuIdLeaf id="8" eax="0" ebx="0" ecx="0" edx="0"/>
          <CpuIdLeaf id="9" eax="0" ebx="0" ecx="0" edx="0"/>
          <CpuIdLeaf id="10" eax="120587267" ebx="0" ecx="0" edx="1539"/>
          <CpuIdLeaf id="2147483648" eax="2147483656" ebx="0" ecx="0" edx="0"/>
          <CpuIdLeaf id="2147483649" eax="0" ebx="0" ecx="1" edx="739248128"/>
          <CpuIdLeaf id="2147483650" eax="538976288" ebx="1226842144" ecx="1818588270" edx="539578920"/>
          <CpuIdLeaf id="2147483651" eax="1701998403" ebx="692933672" ecx="758606112" edx="808663347"/>
          <CpuIdLeaf id="2147483652" eax="1346576459" ebx="541073493" ecx="808594995" edx="8013895"/>
          <CpuIdLeaf id="2147483653" eax="0" ebx="0" ecx="0" edx="0"/>
          <CpuIdLeaf id="2147483654" eax="0" ebx="0" ecx="16801856" edx="0"/>
          <CpuIdLeaf id="2147483655" eax="0" ebx="0" ecx="0" edx="256"/>
          <CpuIdLeaf id="2147483656" eax="12334" ebx="0" ecx="0" edx="0"/>
        </CpuIdTree>

which should be the exact same values returned by my host. I'm sure VirtualBox would have to modify the values, but it seems as though nothing's going through to the guest.

[Joel Low]

Would it be better if I open another ticket instead?

[Joel Low]

Bump please. Is there any interest still in the symthcpu option?

[Joel Low]

Bump again, please.

[Frank Mehnert]

It turned out that the 'synthcpu' option is not that useful, especially not for Windows guests. Because Windows does not only respect the provided CPU feature flags but also depends a lot on the CPU vendor. Therefore with Windows it is almost impossible to implement a synthetic CPU to be able to migrate a VM from an AMD host to an Intel host (this was the original idea of the synthetic CPU option). When we found this out, we decreased the priority of bug reports related to 'synthcpu'.

[Joel Low]

Ah, would it be helpful for Intel -> Intel migrations though? Where I am we purely use Intel CPUs.

[Frank Mehnert]

Same problem there. Many guests (not only Windows) are not exact enough when considering the CPU features.

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.