From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFOdQ-0004eH-Ho for qemu-devel@nongnu.org; Mon, 17 Feb 2014 08:53:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFOdK-0004Ci-3H for qemu-devel@nongnu.org; Mon, 17 Feb 2014 08:53:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18952) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFOdJ-0004CJ-Rc for qemu-devel@nongnu.org; Mon, 17 Feb 2014 08:53:18 -0500 Date: Mon, 17 Feb 2014 15:58:13 +0200 From: "Michael S. Tsirkin" Message-ID: <20140217135813.GA22709@redhat.com> 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> <52F0F55B.5050103@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <52F0F55B.5050103@suse.de> 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: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: Eduardo Habkost , qemu-devel@nongnu.org, Bandan Das , Anthony Liguori , Igor Mammedov , Paolo Bonzini On Tue, Feb 04, 2014 at 03:12:43PM +0100, Andreas F=E4rber wrote: > 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 w= ith a > >>> commit changing such a thing - either it did not go through my queu= e 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 resul= t is > >>>>> used to trim the generic feature bits. > >>> Our model definitions are the place to put stuff that real CPUs hav= e. > >>> 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 addin= g > >>> 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 Pa= olo > > and me? >=20 > Yes, I am. I had proposed to discuss solutions at FOSDEM but Paolo was > not there, so no solution yet. We have the weekly call tomorrow. Let's discuss there? > 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. Why is this a problem? We will just have to make sure features stay consistent for old -M machine types. > 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) >=20 > Regards, > Andreas >=20 > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg