qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 00/13] add support for Hypervisor.framework i


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2 00/13] add support for Hypervisor.framework in QEMU
Date: Thu, 31 Aug 2017 10:34:00 +0100
User-agent: Mutt/1.8.3 (2017-05-23)

On Wed, Aug 30, 2017 at 03:26:49AM -0500, Sergio Andres Gomez Del Real wrote:
> ================
> Changes in v2:
>  (1) Removed legacy option "-enable-hvf" in favor of "-M accel=hvf"
>  (2) Added missing copyright headers; replace fprintfs for error_report;
>      improved commit description.
>  (3) Moved patch that adds compilation rules in Makefile.objs right after
>      the patch that adds the new files from Google's repo.
>  (4) Removed conditional macros from cpus.c and cpu.c
>  (5) Moved patch that fixes coding style to patch # 3
>  (6) Fix commit message in apic patch
>  (7) Squash some commits to avoid code churn
> ================
> 
> The following patchset adds to QEMU the supporting for macOS's native
> hypervisor, Hypervisor.framework (hvf). The code base is taken from
> Google's Android emulator at
> https://android.googlesource.com/platform/external/qemu/+/emu-master-dev.
> 
> Apart from general code refactoring, some additional features were 
> implemented:
> retrieve the set of features supported by host cpu and hvf (cpuid);
> dirty page tracking for VGA memory area; reimplementation of the event
> injection mechanism to allow injection of exceptions during vmexits, which is
> exemplified by the injection of a GP fault when the guest vmexits due to
> execution of the vmcall instruction; changing the emulator's use of CPUState
> structure in favor of CPUX86State, so as to in the future remove data 
> structures
> that are uselessly specific to hvf and unified some of the state between 
> kvm/tcg
> and hvf.
> Some features initially planned to implement that didn't make it include:
> page fault handling in the emulator and implementing the dummy_signal to 
> handle
> the SIG_IPI signal without race conditions. Hopefully these can be implemented
> in the near future.

I have done a brief review (mainly style issues) of the whole series.

A test case is required.  Maybe the easiest option is to extend
tests/boot-serial-test.c to try hvf (if available).  That way an
automated test will verify that the BIOS executes inside the guest.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]