[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a24c23bc-cdd2-8ad1-972d-b89ea585f4f1@redhat.com>
Date: Wed, 26 Apr 2017 09:48:22 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Borislav Petkov <bp@...en8.de>,
Satoru Takeuchi <satoru.takeuchi@...il.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
kvm ML <kvm@...r.kernel.org>
Subject: Re: [BUG] x86: failed to boot a kernel on a Ryzen machine
On 25/04/2017 11:36, Borislav Petkov wrote:
> Looking at CR4: 00000000003006f0, it doesn't have OSXSAVE set. I.e., bit
> 18. And when that bit is not set, VMOVDQA raises an #UD.
>
> And for some reason qemu doesn't like it even if you request that bit with
> +osxsave:
>
> warning: host doesn't support requested feature: CPUID.01H:ECX.osxsave [bit 27]
>
> Even though the corresponding bit in CPUID on the host is set:
>
> 0x00000001: EAX=0x00800f00, EBX=0x40200800, ECX=0x7ed8320b, EDX=0x178bfbff
> ^
> Paolo, any thoughts?
The OSXSAVE CPUID bit is not set by QEMU, it is set by the OS itself
(indirectly) when it sets CR4.OSXSAVE. QEMU says it's not available
(probably) because the Opteron_G3 CPU model does not have the 0xD CPUID
leaf.
I think you're using libvirt's "host-model" CPU model. That model needs
QEMU/libvirt support for each host CPU family, and in general it often
gives rise to bugs such as the one you're reporting,
Change it to host-passthrough, and please send us the output of
/proc/cpuinfo so we can add support for Ryzen in "host-model".
Thanks,
Paolo
Powered by blists - more mailing lists