From: Phil Dennis-Jordan <phil@philjordan.eu>
To: qemu-devel@nongnu.org
Cc: dirty@apple.com, roman@roolebo.dev, pbonzini@redhat.com,
lists@philjordan.eu, phil@philjordan.eu
Subject: [PATCH v2 0/4] hvf x86 correctness and efficiency improvements part 1
Date: Sat, 21 Oct 2023 22:05:14 +0200 [thread overview]
Message-ID: <20231021200518.30125-1-phil@philjordan.eu> (raw)
This is a series of semi-related patches for the x86 macOS Hypervisor.framework
(hvf) accelerator backend. The intention is to (1) fix bugs and (2) move the
hvf backend to use more modern and efficient APIs in Hypervisor.framework.
The eventual goal is to replace the main hv_vcpu_run() call with
hv_vcpu_run_until(); the final 2 patches for this were included in v1 of this
series, but I've omitted them until part 2 this time around, as discussion
raised some questions about edge cases and race conditions when forcing VM
exits. I'm still working on getting solid answers on those questions and will
only then follow up with corresponding patches. Until then, this first set
of changes lays some groundwork.
Patch 1 enables the INVTSC CPUID bit when running with hvf. This can enable
some optimisations in the guest OS, and I've not found any reason it shouldn't
be allowed for hvf based hosts. It now also includes setting a migration
blocker when the feature is active.
Patch 2 fixes a bunch of compile warnings that kept littering my build logs,
so I finally caved and fixed them. As far as I can tell, these were all
ancient typos.
Patch 3 sorts out the minor mess of hvf vCPU IDs/handles. The aarch64 and
x86-64 versions of Hypervisor.framework's APIs use different integral types
(uint64_t vs unsigned int) when referencing vCPUs, so this changes the code
to use the correct one depending on build arch instead of awkward pointer
casts. (There's currently only one instance of such a cast, but the patches
in part 2 would have added more, so I'm fixing this preemptively.)
Patch 4 fixes dirty page tracking for the x86 hvf backend. This has
previously only accidentally worked because hv_vcpu_run() makes spurious EPT
fault exits. Switching to hv_vcpu_run_until() surfaces this issue when using
an emulated VGA adapter for example, as those use dirty page tracking to do
partial screen updates.
changelog:
v2:
- Migration blocker when INVTSC is set (Thanks Paolo for pointing that out!)
- Dirty page tracking fix (Thanks Roman for noticing the regression in
observed behaviour on certain VMs, which led me to debugging this issue.)
- vCPU handle type cleanup (Based on discussion with Paolo)
- Added fixes for existing compile warnings.
- Split patch series into 2 parts.
This work has been sponsored by Sauce Labs Inc.
Phil Dennis-Jordan (4):
i386: hvf: Adds support for INVTSC cpuid bit
hvf: Fixes some compilation warnings
hvf: Consistent types for vCPU handles
i386/hvf: Fixes dirty memory tracking by page granularity RX->RWX
change
accel/hvf/hvf-accel-ops.c | 2 +-
include/sysemu/hvf_int.h | 4 +++-
target/i386/hvf/hvf.c | 23 +++++++++++++++++++++--
target/i386/hvf/vmx.h | 3 +--
target/i386/hvf/x86_cpuid.c | 4 ++++
target/i386/hvf/x86_decode.c | 2 +-
target/i386/hvf/x86_emu.c | 4 ++--
7 files changed, 33 insertions(+), 9 deletions(-)
--
2.36.1
next reply other threads:[~2023-10-21 20:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-21 20:05 Phil Dennis-Jordan [this message]
2023-10-21 20:05 ` [PATCH v2 1/4] i386: hvf: Adds support for INVTSC cpuid bit Phil Dennis-Jordan
2023-11-06 5:10 ` Roman Bolshakov
2023-10-21 20:05 ` [PATCH v2 2/4] hvf: Fixes some compilation warnings Phil Dennis-Jordan
2023-11-06 5:16 ` Roman Bolshakov
2023-10-21 20:05 ` [PATCH v2 3/4] hvf: Consistent types for vCPU handles Phil Dennis-Jordan
2023-11-06 5:24 ` Roman Bolshakov
2023-10-21 20:05 ` [PATCH v2 4/4] i386/hvf: Fixes dirty memory tracking by page granularity RX->RWX change Phil Dennis-Jordan
2023-11-06 8:53 ` Roman Bolshakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231021200518.30125-1-phil@philjordan.eu \
--to=phil@philjordan.eu \
--cc=dirty@apple.com \
--cc=lists@philjordan.eu \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=roman@roolebo.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).