106f91d59c
The CPUID function 1 has a bit called OSXSAVE which tells user space the status of the CR4.OSXSAVE bit. Our generic CPUID function injects that bit based on the status of CR4. With Hypervisor.framework, we do not synchronize full CPU state often enough for this function to see the CR4 update before guest user space asks for it. To be on the save side, let's just always synchronize it when we receive a CPUID(1) request. That way we can set the bit with real confidence. Reported-by: Asad Ali <asad@osaro.com> Signed-off-by: Alexander Graf <agraf@csgraf.de> Message-Id: <20210123004129.6364-1-agraf@csgraf.de> [RB: resolved conflict with another CPUID change] Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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:
- Adapt to our current QEMU's
CPUStatestructure andaddress_space_rwAPI; many struct members have been moved around (emulated x86 state, xsave_buf) due to historical differences + QEMU needing to handle more emulation targets. - Removal of
apic_pageand hyperv-related functionality. - More relaxed use of
qemu_mutex_lock_iothread.