From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAgkC-0003rI-J7 for qemu-devel@nongnu.org; Tue, 04 Feb 2014 09:13:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAgk3-0004BM-BU for qemu-devel@nongnu.org; Tue, 04 Feb 2014 09:12:56 -0500 Received: from cantor2.suse.de ([195.135.220.15]:38632 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAgk3-0004BD-5l for qemu-devel@nongnu.org; Tue, 04 Feb 2014 09:12:47 -0500 Message-ID: <52F0F55B.5050103@suse.de> Date: Tue, 04 Feb 2014 15:12:43 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1390228618-21663-1-git-send-email-ehabkost@redhat.com> <52DD9F77.4040904@suse.de> <52DE45E3.5010208@redhat.com> <52DE978E.3020309@suse.de> <52DE9CBE.7080009@redhat.com> <20140203190114.GL24353@otherpad.lan.raisama.net> In-Reply-To: <20140203190114.GL24353@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recent CPU models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Paolo Bonzini Cc: Igor Mammedov , Bandan Das , qemu-devel@nongnu.org, Anthony Liguori , "Michael S. Tsirkin" Am 03.02.2014 20:01, schrieb Eduardo Habkost: > On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wrote: >> Il 21/01/2014 16:51, Andreas F=E4rber ha scritto: >>>>> We already do that for other bits (e.g. XSAVE/OSXSAVE), >>> Please point me to the commit, a search for xsave did not come up wit= h a >>> commit changing such a thing - either it did not go through my queue = or >>> it slipped me through: Bugs are no excuse to produce more bugs. >> >> I meant that "-cpu SandyBridge" with TCG produces a CPU that doesn't >> have XSAVE. >> >>>>> and in fact it >>>>> is the same that we do for KVM: the KVM_GET_SUPPORTED_CPUID result = is >>>>> used to trim the generic feature bits. >>> Our model definitions are the place to put stuff that real CPUs have. >>> Either the CPU has it or it doesn't. If it does, then this patch is >>> fully correct and it's TCG's job to mask things out. If we're adding >>> artificial flags to the generic model definitions just to make KVM >>> faster, then it is wrong - we have a choice of post_initialize and >>> realize hooks for that. >> >> It would make TCG faster as well, and there would be no reason >> really to avoid the "artificial" x2apic on TCG, if TCG implemented >> x2apic at all. >=20 > So, the discussion seem to have stalled. >=20 > Andreas, are you still against the patch, after the arguments from Paol= o > and me? Yes, I am. I had proposed to discuss solutions at FOSDEM but Paolo was not there, so no solution yet. My main concern still is that if a CPU does not have a certain feature we should not list it as one of its features but add it to its features where sensible. Just because TCG filters it out today is not keeping anyone from implementing it tomorrow, in which case the emulated CPUs would suddenly gain the feature. So my question still is, what rule can we apply for enabling x2apic? (something like greater or equal this family, etc. - then we can put it in your post_initialize hook so that users can still override it) Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg