Open mborgerson opened 6 years ago
Regarding the target issue, please consider https://github.com/xqemu/xqemu.com/pull/22#discussion_r214890594
It should be easy enough to add building these accelerators for any machine type instead of abusing an existing machine.
QEMU 3.1 was released this month: https://wiki.qemu.org/ChangeLog/3.1
HVF: Instruction emulation has been improved.
I'm not sure if this is beneficial for us.
It probably is. I had planned on merging in 3.1 updates soonish.
Oh that reminds me. Thank you both for commenting on that QEMU's emulation topic. I wanted to know exactly what of the old x86-type architecture/CPU families that QEMU emulates currently. QEMU has surprisingly very poor documentation of the CPU ranges based on the x86 architecture that it is presumed to emulate.
Does it emulate effectively the 8086/8088 (Intel's oldest CPUs), 80286, 80386, 80486, Pentium I and its variants; and Pentium II. What about also the Pentium III and 4? Sorry for going a bit off-topic. But there are emulators that emulate many of the above early Intel architecture. So we just need to know.
Ask on QEMU channels, not here. This issue is specifially about HVF acceleration being broken for Xbox emulation.
My understanding: What QEMU supports depends on the CPU backend. So for hardware virtualization it primarily depends on your host CPU, and for TCG I'd assume that most recent x86 features are supported. You can also set a custom cpuid (which doesn't necessarily affect emulation). Xbox emulation requires Pentium 3 features, and that works fine.
Unfortunately, HVF is only usable on the x86_64 target, that's okay though because it should be compatible with i386 (it is architecturally anyway). When building the x86_64-softmmu target (simply add it to the
--target-list
), XQEMU does get farther in the boot process as the main window is displayed, but that's about it. Needs further investigation. I can however boot with HVF acceleration with the default machine type. Possibly related to memory changes?It seems like GDB support is broken on HVF. When running with the default machine (which boots to some PXE loader) then connecting with GDB we see the CPU at the reset vector and cannot
continue
the machine...HAX halts at least in GDB. The QEMU monitor seems to be able to correctly halt the CPU.Update: While it would be nice to have support for the native hypervisor on macOS, I think HAXM is the way to go--so I consider this issue to now be very low priority (I don't plan to spend any time on it). HAXM has finally been proven viable for XQEMU after some fixes, it's open source (enabling us to fix issues / add features), and it works on both macOS and Windows.