From: Phil Dennis-Jordan <lists@philjordan.eu>
To: Phil Dennis-Jordan <phil@philjordan.eu>
Cc: qemu-devel@nongnu.org, dirty@apple.com, rbolshakov@ddn.com
Subject: Re: [PATCH 0/3] hvf x86 correctness and efficiency improvements
Date: Thu, 5 Oct 2023 22:30:39 +0200 [thread overview]
Message-ID: <CAGCz3vt7Mb_E5WQ860BTvO0-LBQJDnzfJ9ykTsCYFM2GDdguWQ@mail.gmail.com> (raw)
In-Reply-To: <20230922140914.13906-1-phil@philjordan.eu>
Ping - let me know if there's anything particularly controversial,
unclear, etc. about these patches or if I can do anything to make
reviewing easier.
Thanks!
On Fri, 22 Sept 2023 at 16:09, Phil Dennis-Jordan <phil@philjordan.eu> wrote:
>
> This is a series of semi-related patches for the x86 macOS Hypervisor.framework
> (hvf) accelerator backend. The intention is to make VMs run slightly more
> efficiently on macOS host machines. They have been subject to some months of
> CI workloads with macOS guest VMs without issues and they seem to give a few
> percent performance improvement. (Though this varies greatly with the type of
> workload.)
>
> 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.
>
> Patch 2 fixes hvf_kick_vcpu_thread so it actually forces a VM exit instead of
> doing nothing. I guess this previously didn't cause any huge issues because
> hvf's hv_vcpu_run() would exit so extremely frequently on its own accord. The
> temp variable is needed because the pointer expected by the hv_vcpu_interrupt()
> call doesn't match the fd field's type in the hvf accel's struct AccelCPUState.
> I'm unsure if it would be better to change that struct field to the relevant
> architecture's handle types, hv_vcpuid_t (x86, unsigned int) and hv_vcpu_t
> (aarch64, uint64_t), perhaps via an intermediate typedef?
>
> Patch 3, which replaces the call to hv_vcpu_run() with the more modern
> hv_vcpu_run_until() for running the guest vCPU. The newer API is available
> from macOS 10.15 host systems onwards. This call causes significantly fewer
> VM exits, which also means we really need that exit-forcing interrupt from
> patch 2. The reduction in VM exits means less overhead from exits and less
> contention on the BQL. Using hv_vcpu_run_until() is also a prerequisite for
> using certain newer hvf features, though this patchset doesn't use any.
>
> Patches 2 & 3 must therefore be applied in that order, patch 1 is independent.
>
> This work has been sponsored by Sauce Labs Inc.
>
> Phil Dennis-Jordan (3):
> i386: hvf: Adds support for INVTSC cpuid bit
> i386: hvf: In kick_vcpu use hv_vcpu_interrupt to force exit
> i386: hvf: Updates API usage to use modern vCPU run function
>
> target/i386/hvf/hvf.c | 26 +++++++++++++++++++++++++-
> target/i386/hvf/x86_cpuid.c | 4 ++++
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> --
> 2.36.1
>
next prev parent reply other threads:[~2023-10-05 20:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-22 14:09 [PATCH 0/3] hvf x86 correctness and efficiency improvements Phil Dennis-Jordan
2023-09-22 14:09 ` [PATCH 1/3] i386: hvf: Adds support for INVTSC cpuid bit Phil Dennis-Jordan
2023-10-08 18:07 ` Roman Bolshakov
2023-09-22 14:09 ` [PATCH 2/3] i386: hvf: In kick_vcpu use hv_vcpu_interrupt to force exit Phil Dennis-Jordan
2023-10-08 18:23 ` Roman Bolshakov
2023-10-08 18:39 ` Phil Dennis-Jordan
2023-10-08 19:19 ` Roman Bolshakov
2023-10-08 19:29 ` Phil Dennis-Jordan
2023-10-16 14:19 ` Phil Dennis-Jordan
2023-10-20 15:12 ` Phil Dennis-Jordan
2023-11-05 15:21 ` Roman Bolshakov
2023-11-06 14:15 ` Phil Dennis-Jordan
2023-09-22 14:09 ` [PATCH 3/3] i386: hvf: Updates API usage to use modern vCPU run function Phil Dennis-Jordan
2023-10-05 20:30 ` Phil Dennis-Jordan [this message]
2023-10-16 14:39 ` [PATCH 0/3] hvf x86 correctness and efficiency improvements Paolo Bonzini
2023-10-16 16:45 ` Phil Dennis-Jordan
2023-10-16 16:48 ` Paolo Bonzini
2023-10-16 20:05 ` Phil Dennis-Jordan
2023-10-16 21:08 ` Paolo Bonzini
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=CAGCz3vt7Mb_E5WQ860BTvO0-LBQJDnzfJ9ykTsCYFM2GDdguWQ@mail.gmail.com \
--to=lists@philjordan.eu \
--cc=dirty@apple.com \
--cc=phil@philjordan.eu \
--cc=qemu-devel@nongnu.org \
--cc=rbolshakov@ddn.com \
/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).