qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]