From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5uT8-0001bU-7P for qemu-devel@nongnu.org; Fri, 19 Jun 2015 07:28:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5uT4-0006wR-UM for qemu-devel@nongnu.org; Fri, 19 Jun 2015 07:28:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5uT4-0006vS-PR for qemu-devel@nongnu.org; Fri, 19 Jun 2015 07:28:18 -0400 Date: Fri, 19 Jun 2015 13:28:14 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20150619112814.GD10217@potion.brq.redhat.com> 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> <20150619094756.GB10217@potion.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150619094756.GB10217@potion.brq.redhat.com> 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, bsd@redhat.com, qemu-devel@nongnu.org, rth@twiddle.net 2015-06-19 11:47+0200, Radim Kr=C4=8Dm=C3=A1=C5=99: > 2015-06-18 12:50-0300, Eduardo Habkost: > > I have considered introducing "min-[x]level" and "max-{x]level" > > properties to control automatic increasing of level/xlevel. The exist= ing > > X86CPUDefinition.level field could just control min_level, while > > explicit "level=3D" on the command-line or config file would explicit= ly > > force a specific value. Probably setting "max-level" on machine-type > > compat code would be enough to restore the previous behavior. >=20 > We'd need to set min-level at least to 7, to capture the raising we do > now, but a feature in level between default and 7 would result in a > different behavior, so we need to make it much uglier :/ > We can add 'compat-level' bit for old machine types and raise to highes= t > habited function otherwise, optionally with controls you described. No, features are only in 0x7 and 0xd, so the original solution is good. (We should also be bumping the CPUID level when adding specific features, e.g. to at least 0xB when x2apic is selected.)