[PATCH v2 0/5] hvf: stability fixes for HVF

Cameron Esfahani via posted 5 patches 5 years, 11 months ago
Test asan passed
Test checkpatch passed
Test FreeBSD passed
Test docker-mingw@fedora passed
Test docker-clang@ubuntu passed
Test docker-quick@centos7 passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/cover.1574625592.git.dirty@apple.com
Maintainers: Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson <rth@twiddle.net>, Eduardo Habkost <ehabkost@redhat.com>
There is a newer version of this series
target/i386/hvf/hvf.c        | 79 ++++++++++++++++++++++++++----------
target/i386/hvf/vmx.h        | 18 ++++----
target/i386/hvf/x86_decode.c | 64 ++++++++++++++++-------------
target/i386/hvf/x86_decode.h | 20 ++++-----
target/i386/hvf/x86_emu.c    |  3 --
target/i386/hvf/x86hvf.c     | 26 +++++-------
6 files changed, 124 insertions(+), 86 deletions(-)
[PATCH v2 0/5] hvf: stability fixes for HVF
Posted by Cameron Esfahani via 5 years, 11 months ago
The following patches fix stability issues with running QEMU on Apple
Hypervisor Framework (HVF):
- non-RAM, non-ROMD areas need to trap so accesses can be correctly
  emulated.
- Current TSC synchronization implementation is insufficient: when
  running with more than 1 core, TSC values can go backwards.  Until
  a correct implementation can be written, remove calls to
  hv_vm_sync_tsc().  Pass through TSC to guest OS.
- Fix REX emulation in relation to legacy prefixes.
- More correctly match SDM when setting CR0 and PDPTE registers.
- Save away exception type as well as vector in hvf_store_events() so
  they can be correctly reinjected in hvf_inject_interrupts().  Under
  heavy loads, exceptions got misrouted.

Changes in v2:
- Fix code style errors.

Cameron Esfahani (5):
  hvf: non-RAM, non-ROMD memory ranges are now correctly mapped in
  hvf: remove TSC synchronization code because it isn't fully complete
  hvf: correctly handle REX prefix in relation to legacy prefixes
  hvf: more accurately match SDM when setting CR0 and PDPTE registers
  hvf: save away type as well as vector so we can reinject them

 target/i386/hvf/hvf.c        | 79 ++++++++++++++++++++++++++----------
 target/i386/hvf/vmx.h        | 18 ++++----
 target/i386/hvf/x86_decode.c | 64 ++++++++++++++++-------------
 target/i386/hvf/x86_decode.h | 20 ++++-----
 target/i386/hvf/x86_emu.c    |  3 --
 target/i386/hvf/x86hvf.c     | 26 +++++-------
 6 files changed, 124 insertions(+), 86 deletions(-)

-- 
2.24.0


Re: [PATCH v2 0/5] hvf: stability fixes for HVF
Posted by Paolo Bonzini 5 years, 11 months ago
On 24/11/19 21:05, Cameron Esfahani wrote:
> The following patches fix stability issues with running QEMU on Apple
> Hypervisor Framework (HVF):
> - non-RAM, non-ROMD areas need to trap so accesses can be correctly
>   emulated.
> - Current TSC synchronization implementation is insufficient: when
>   running with more than 1 core, TSC values can go backwards.  Until
>   a correct implementation can be written, remove calls to
>   hv_vm_sync_tsc().  Pass through TSC to guest OS.
> - Fix REX emulation in relation to legacy prefixes.
> - More correctly match SDM when setting CR0 and PDPTE registers.
> - Save away exception type as well as vector in hvf_store_events() so
>   they can be correctly reinjected in hvf_inject_interrupts().  Under
>   heavy loads, exceptions got misrouted.

Certainly no doubt about patches 1-4, while for patch 5 I'm wondering if
it's masking another bug; I'd prefer to have also some assertions that
interrupt_injected is never an exception and exception_nr is never an
interrupt.

Peter, can you apply patches 1-4 directly?  I cannot even compile-test
them right now, but they are obviously bugfixes.

Paolo


Re: [PATCH v2 0/5] hvf: stability fixes for HVF
Posted by Cameron Esfahani via 5 years, 11 months ago
Let me see if I can add some assertions.

Cameron Esfahani
dirty@apple.com

"The cake is a lie."

Common wisdom



> On Nov 25, 2019, at 2:28 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> Certainly no doubt about patches 1-4, while for patch 5 I'm wondering if
> it's masking another bug; I'd prefer to have also some assertions that
> interrupt_injected is never an exception and exception_nr is never an
> interrupt.
>