[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] x86: Fix Opteron xlevels
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH] x86: Fix Opteron xlevels |
Date: |
Wed, 22 Apr 2015 11:23:49 -0300 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Tue, Apr 21, 2015 at 04:15:14PM +0200, Alexander Graf wrote:
> On 04/21/2015 04:16 PM, Eduardo Habkost wrote:
> >On Tue, Apr 21, 2015 at 04:04:21PM +0200, Alexander Graf wrote:
> >>The AMD Opteron family has different xlevel levels depending on the
> >>generation. I looked up Gen1, Gen2 and Gen3 hardware and adapted the
> >>levels according to real silicon.
> >>
> >>The reason this came up is that there is a sanity check in KVM making
> >>sure that SVM is only used when xlevel is high enough. Using real
> >>hardware levels, they now are.
> >>
> >>Reported-by: Bernhard M. Wiedemann <address@hidden>
> >>Signed-off-by: Alexander Graf <address@hidden>
> >It needs compatibility properties in HW_COMPAT_2_1. See commit
> >6b11322e0f724eb0649fdc324a44288b783023ad for reference.
>
> Ah, sure, will do.
>
> >
> >>---
> >> target-i386/cpu.c | 6 +++---
> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >>diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> >>index 03b33cf..d1b1b8c 100644
> >>--- a/target-i386/cpu.c
> >>+++ b/target-i386/cpu.c
> >>@@ -1234,7 +1234,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
> >> CPUID_EXT2_MTRR | CPUID_EXT2_SYSCALL | CPUID_EXT2_APIC |
> >> CPUID_EXT2_CX8 | CPUID_EXT2_MCE | CPUID_EXT2_PAE |
> >> CPUID_EXT2_MSR |
> >> CPUID_EXT2_TSC | CPUID_EXT2_PSE | CPUID_EXT2_DE |
> >> CPUID_EXT2_FPU,
> >>- .xlevel = 0x80000008,
> >>+ .xlevel = 0x80000018,
> >Why did you choose 0x80000018? The highest 0x80000000 leaf we implement
> >today is 0x8000000A. SVM info is at 0x8000000A.
>
> Because it's what real hardware exposes ;).
Real hardware exposes 0x80000018 because it does return useful
information in some of the 0x8000000B-0x80000018 leaves.
We don't return anything useful in CPUID leaves above 0x8000000a[1], so
what exactly are you trying to do by reporting leaves
0x8000000B-0x80000018 as available?
[1] I don't even know what's present in those leaves. I will check the
Intel and AMD docs right now.
--
Eduardo