On Sat, Jan 23, 2021 at 01:41:29AM +0100, Alexander Graf wrote:
> 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 <a...@osaro.com>
> Signed-off-by: Alexander Graf <ag...@csgraf.de>
> ---
> target/i386/hvf/hvf.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
> index 08b4adecd9..f660b829ac 100644
> --- a/target/i386/hvf/hvf.c
> +++ b/target/i386/hvf/hvf.c
> @@ -426,6 +426,10 @@ int hvf_vcpu_exec(CPUState *cpu)
> uint32_t rcx = (uint32_t)rreg(cpu->hvf->fd, HV_X86_RCX);
> uint32_t rdx = (uint32_t)rreg(cpu->hvf->fd, HV_X86_RDX);
>
> + if (rax == 1) {
> + /* CPUID1.ecx.OSXSAVE needs to know CR4 */
> + env->cr[4] = rvmcs(cpu->hvf->fd, VMCS_GUEST_CR4);
> + }
> cpu_x86_cpuid(env, rax, rcx, &rax, &rbx, &rcx, &rdx);
>
> wreg(cpu->hvf->fd, HV_X86_RAX, rax);
> --
> 2.24.3 (Apple Git-128)
>
The fix is based off hvf-arm patch series and doesn't build on
master branch because of "cpu->hvf->fd" has to be "cpu->hvf_fd".
I've corrected the issue and resolved conflicts with another patch in
hvf-queue. So, it's been queued.
Thanks,
Roman
