From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5dMk-0005CO-2Y for qemu-devel@nongnu.org; Thu, 18 Jun 2015 13:12:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5dMi-000110-6F for qemu-devel@nongnu.org; Thu, 18 Jun 2015 13:12:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5dMi-00010V-01 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 13:12:36 -0400 From: Bandan Das References: <1434641064-8405-1-git-send-email-rkrcmar@redhat.com> <1434641064-8405-3-git-send-email-rkrcmar@redhat.com> <20150618155046.GC3874@thinpad.lan.raisama.net> Date: Thu, 18 Jun 2015 13:12:32 -0400 In-Reply-To: <20150618155046.GC3874@thinpad.lan.raisama.net> (Eduardo Habkost's message of "Thu, 18 Jun 2015 12:50:46 -0300") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/2] target-i386: automatically raise cpuid level to 0xd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: pbonzini@redhat.com, rth@twiddle.net, qemu-devel@nongnu.org, Radim =?utf-8?B?S3LEjW3DocWZ?= Eduardo Habkost writes: > On Thu, Jun 18, 2015 at 05:24:24PM +0200, Radim Kr=C4=8Dm=C3=A1=C5=99 wro= te: >> We already bump to level 7 if features there are requested, so do the >> same for 0xD. But doesn't bumping to 7 for feat[ebx] have the potential to break ABI too ? >> Signed-off-by: Radim Kr=C4=8Dm=C3=A1=C5=99 > > This breaks guest ABI and live-migration, as CPUID data is not part of > the migration stream (although we have considered including it in the > future). > > If we are going to add more special cases like this, we must provide a > way to make QEMU honour an explicit "level" option from the config file > or command-line. > > I have considered introducing "min-[x]level" and "max-{x]level" > properties to control automatic increasing of level/xlevel. The existing > X86CPUDefinition.level field could just control min_level, while > explicit "level=3D" on the command-line or config file would explicitly > force a specific value. Probably setting "max-level" on machine-type > compat code would be enough to restore the previous behavior. > > >> --- >> If we want this behavior, we should not do it by writing a case for >> every level. Agreed, we should really have a more generic way of doing this. Bandan >> target-i386/cpu.c | 4 ++++ >> 1 file changed, 4 insertions(+) >>=20 >> diff --git a/target-i386/cpu.c b/target-i386/cpu.c >> index d392cf46f517..7a32ead690d2 100644 >> --- a/target-i386/cpu.c >> +++ b/target-i386/cpu.c >> @@ -2796,6 +2796,10 @@ static void x86_cpu_realizefn(DeviceState *dev, E= rror **errp) >> env->cpuid_level =3D 7; >> } >>=20=20 >> + if (env->features[FEAT_XSAVE] && env->cpuid_level < 0xd) { >> + env->cpuid_level =3D 0xd; >> + } >> + >> /* On AMD CPUs, some CPUID[8000_0001].EDX bits must match the bits = on >> * CPUID[1].EDX. >> */ >> --=20 >> 2.4.4 >>=20