mirror_qemu/target/i386/hvf
Peter Maydell 19f7034773 Avoid address_space_rw() with a constant is_write argument
The address_space_rw() function allows either reads or writes
depending on the is_write argument passed to it; this is useful
when the direction of the access is determined programmatically
(as for instance when handling the KVM_EXIT_MMIO exit reason).
Under the hood it just calls either address_space_write() or
address_space_read_full().

We also use it a lot with a constant is_write argument, though,
which has two issues:
 * when reading "address_space_rw(..., 1)" this is less
   immediately clear to the reader as being a write than
   "address_space_write(...)"
 * calling address_space_rw() bypasses the optimization
   in address_space_read() that fast-paths reads of a
   fixed length

This commit was produced with the included Coccinelle script
scripts/coccinelle/exec_rw_const.cocci.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20200218112457.22712-1-peter.maydell@linaro.org>
[PMD: Update macvm_set_cr0() reported by Laurent Vivier]
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-20 14:47:08 +01:00
..
Makefile.objs
README.md i386: Compile CPUX86State xsave_buf only when support KVM or HVF 2018-10-02 19:09:12 +02:00
hvf-i386.h Clean up ill-advised or unusual header guards 2019-05-13 08:58:55 +02:00
hvf.c hvf: correctly inject VMCS_INTR_T_HWINTR versus VMCS_INTR_T_SWINTR. 2019-12-03 09:11:42 +01:00
panic.h i386: hvf: cleanup x86_gen.h 2017-12-22 15:02:07 +01:00
vmcs.h Clean up ill-advised or unusual header guards 2019-05-13 08:58:55 +02:00
vmx.h Avoid address_space_rw() with a constant is_write argument 2020-02-20 14:47:08 +01:00
x86.c i386: hvf: remove addr_t 2017-12-22 15:02:07 +01:00
x86.h Normalize header guard symbol definition. 2019-05-13 08:58:55 +02:00
x86_cpuid.c target/i386: drop the duplicated definition of cpuid AVX512_VBMI macro 2019-10-15 18:34:44 -03:00
x86_decode.c hvf: correctly handle REX prefix in relation to legacy prefixes 2019-11-26 09:58:36 +01:00
x86_decode.h hvf: correctly handle REX prefix in relation to legacy prefixes 2019-11-26 09:58:36 +01:00
x86_descr.c i386: hvf: unify register enums between HVF and the rest 2017-12-22 15:02:07 +01:00
x86_descr.h Normalize header guard symbol definition. 2019-05-13 08:58:55 +02:00
x86_emu.c target/i386: add a ucode-rev property 2020-01-24 20:59:09 +01:00
x86_emu.h Clean up ill-advised or unusual header guards 2019-05-13 08:58:55 +02:00
x86_flags.c i386: hvf: cleanup x86_gen.h 2017-12-22 15:02:07 +01:00
x86_flags.h Clean up ill-advised or unusual header guards 2019-05-13 08:58:55 +02:00
x86_mmu.c Avoid address_space_rw() with a constant is_write argument 2020-02-20 14:47:08 +01:00
x86_mmu.h Clean up ill-advised or unusual header guards 2019-05-13 08:58:55 +02:00
x86_task.c Clean up inclusion of sysemu/sysemu.h 2019-08-16 13:31:53 +02:00
x86_task.h Clean up header guards that don't match their file name 2019-05-13 08:58:55 +02:00
x86hvf.c hvf: correctly inject VMCS_INTR_T_HWINTR versus VMCS_INTR_T_SWINTR. 2019-12-03 09:11:42 +01:00
x86hvf.h

README.md

OS X Hypervisor.framework support in QEMU

These sources (and ../hvf-all.c) are adapted from Veertu Inc's vdhh (Veertu Desktop Hosted Hypervisor) (last known location: https://github.com/veertuinc/vdhh) with some minor changes, the most significant of which were:

  1. Adapt to our current QEMU's CPUState structure and address_space_rw API; many struct members have been moved around (emulated x86 state, xsave_buf) due to historical differences + QEMU needing to handle more emulation targets.
  2. Removal of apic_page and hyperv-related functionality.
  3. More relaxed use of qemu_mutex_lock_iothread.