No support for Windows guests

[AlexAltea]

I have tried running a Windows 10 ISO (v1804, 64-bit) image on stock QEMU v2.12.50 + HAXM v7.3.2.
However, it seems to get stuck during the kernel boot sequence, i.e. the one with black background and a blue Windows logo. After few minutes, the host kernel crashes (which is also Windows 10 64-bit).
This also affects older Windows versions, such as Windows 7.

I have noticed that previous attempts to run Windows guests where unsuccessful, see #45. However, back then it was due to unsupported instruction emulation, which nowadays has been vastly improved. Do you know what might be causing this? If not, I can always investigate this.

I would be happy to submit a patch adding support for Windows guests myself. Feel free to point me in the right direction if you have any extra information!

[raphaelning]

Thanks, this would be a very useful feature/enhancement for HAXM. I've never tried booting a Windows guest myself, so I can't be of much help at the moment...

However, it seems to get stuck during the kernel boot sequence, i.e. the one with black background and a blue Windows logo.

Wow, to me that's already some progress made, thanks to #42!

After few minutes, the host kernel crashes (which is also Windows 10 64-bit).

This is bad, but at least it can be the starting point of your investigation :) For your convenience, here is IntelHaxm.pdb for the HAXM 7.3.2 release, which you can use to resolve symbols when analyzing the BSOD dump with WinDbg. Of course, you can also rebuild IntelHaxm.sys yourself and obtain the matching .pdb, or debug this issue on Linux.

haxm-windows-v7_3_2-symbols.zip

[raphaelning]

@AlexAltea One of the things that prevent HAXM from booting a Windows (x86_64) guest is the lack of proper CR8 virtualization. See #136 (comment) and #145.

[AlexAltea]

@raphaelning Nice catch! I'll look into CR8 virtualization. Hopefully that will make it progress further.

[raphaelning]

@AlexAltea Thanks. I realized that one of the links I gave you above was wrong, and have fixed it, but you get the idea :-) I think the main challenges are:

1. API change. Since the real CR8 (Task Priority Register, or TPR) is emulated in user space, we may need a new interface for exchanging CR8 state with user space (e.g. adding a new HAX_EXIT_xxx status code). But is it possible to avoid an API change at all? One idea is to translate the CR8 access to an MMIO on the TPR in the emulated APIC device, but I guess the MMIO address depends on the APIC device model.
2. Efficiency. I suppose Windows x86_64 accesses CR8 very often, so if we make an exit to QEMU for every CR8 read/write, the performance won't be good. Does efficient CR8 virtualization require implementing APIC virtualization in HAXM (similar to KVM's in-kernel IRQ chip)?

I'll be on vacation next week, but please feel free to submit a PR or proposal, and I'll review it when I'm back.

[raphaelning]

Update: #180 has confirmed that it is the lack of CR8 virtualization that crashes the 64-bit Windows 10 guest. There's no more host crash.

[coxuintel]

I can’t find the history why it’s disabled in current implementation. @nevilad is working PR#204 to add PAT support. Once some BSOD issues resolved, we’ll merge related patches into mainline.

…

-- Best Regards, Colin Xu From: Fred Madison <notifications@github.com> Sent: Wednesday, November 13, 2019 19:37 To: intel/haxm <haxm@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [intel/haxm] No support for Windows guests (#118) According to reverse engineering of Win10x64 bootloader, CR8 is result of BugCheck and windows installation is stuck because of "// pat is disabled!" in vcpu.c Could you provide some quick answer why it was disabled in current implementation ? Does it contradict with current memory management implementation ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#118?email_source=notifications&email_token=AJ6U7N6CXEJXA7KGHOJCADLQTPRFLA5CNFSM4GBJLYZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED525FI#issuecomment-553365141>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJ6U7N4R2QHSQV2WYIXXHODQTPRFLANCNFSM4GBJLYZA>.

[nevilad]

How did Fred Madison reverse engineered Win10x64 bootloader? Before I added PAT\cr8 support it was stuck and it was easier to find what it checks. Now it runs in an ethernal cycle. Any ideas how to reverse engineer this?

[FreddMadison]

It was useless, since I did not find branch nevilad:win10_support yet. After cpuid fix I cant find this ethernal cycle as well, so I drop it.
Just in case someone knows how to attach WinDbg to Win10 kernel on qemu empty hda vm - it would be possible to move on. For now, qemu fails to install Win10 even in software mode and does not have com2pipe support.

[FreddMadison]

Obviously, since Intel is very concentrated on Android support and haxm comparing to kvm/arch/x86/kvm impl is very very far behind we may see win10x64 support in haxm in several years or never

[nevilad]

It was useless, since I did not find branch nevilad:win10_support yet

https://github.com/nevilad/haxm/tree/win10_support. It supports win10x86, it works on my machine, but Colin says that it fails on Intel machines and he has no time to solve this. It is was forked on May.

For now, qemu fails to install Win10 even in software mode

software mode - tcg? I add "-cpu core2duo" to qemu command line and Win10x64 installation works.

kvm/arch/x86/kvm impl is very very far behind we may see win10x64 support in haxm in several years or never

So far I understand, Intel does not add support to guests other than Android. This is done by the community. I'm trying to add it now.

someone knows how to attach WinDbg to Win10 kernel on qemu empty hda vm - it would be possible to move on.

@AlexAltea added debugging support to haxm, maybe he knows how to do this?