On 17.11.2017 11:30, Yu Ning wrote: > > > On 11/17/2017 16:53, Kamil Rytarowski wrote: >> On 14.11.2017 09:54, Yu Ning wrote: >>> Hello, >>> >>> As some of you may have noticed, since QEMU 2.9.0, an accelerator known >>> as “hax” has been available for Windows and macOS builds of QEMU, thanks >>> to the hard work of Vincent Palatin and help from this community (Paolo >>> Bonzini, Stefan Weil, et al.). >>> >>> The accelerator requires a host kernel module (driver) known as Intel >>> Hardware Accelerated Execution Manager (HAXM), i.e. intelhaxm.sys on >>> Windows or intelhaxm.kext on macOS, similar to how the KVM accelerator >>> depends on kvm.ko on Linux. >>> >>> Today, we released the source code of the HAXM kernel module under the >>> BSD 3-clause license: >>> >>> https://github.com/intel/haxm >>> >>> We look forward to working with the community to improve HAXM (both the >>> kernel module and the accelerator). The code is accompanied by some >>> basic documentation (README.md and API.md), which is incomplete, but >>> hopefully helps people get started. If you have any questions or >>> suggestions, please create an issue or post a comment on GitHub. >>> >>> Thanks, >>> Yu >>> >> Please make it clear whether this module can be ported (as host) to >> other OSes > > It was designed with only Windows and Mac hosts in mind, and we don't > plan to support more host OSes. But porting HAXM to another host OS is > possible. If you take a look at the HAXM source tree, there are pretty > clear boundaries between host-independent code (core/, include/*.h), > Windows-specific code (windows/, include/windows/) and Mac-specific code > (darwin/, include/darwin/).
Sounds good. I will give it a try. >> and whether it can support arbitrary guests OSes (for the >> same CPU). > > Unfortunately not, but again it can be done. Initially HAXM was > designed to support only two guest OSes, namely Android and Tizen. When > we upstreamed the HAXM accelerator module to QEMU, we verified it using > various desktop OS images, mostly Linux-based (Chrome OS, Debian, > Ubuntu, CentOS, etc.), although there were a few others (FreeDOS, etc.). > > Nevertheless, you may run into issues when you boot a completely > different guest OS (e.g. Windows, which we have never tested), or even > with one that is similar to what I've mentioned (e.g. Fedora, which IIRC > will boot to a kernel panic). In such cases, the culprit is usually > bug(s) in the HAXM kernel module, causing incorrect behavior when the > guest executes certain x86 instructions. Once all the bugs exposed by a > specific guest OS are fixed, that guest OS will work correctly. > If it will run BSD for start it will be good enough for now. Thank you for the answers!
signature.asc
Description: OpenPGP digital signature