From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M1l34-0003Q6-1x
	for qemu-devel@nongnu.org; Wed, 06 May 2009 13:36:50 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M1l2z-0003Mr-5c
	for qemu-devel@nongnu.org; Wed, 06 May 2009 13:36:49 -0400
Received: from [199.232.76.173] (port=49585 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M1l2y-0003Mo-Up
	for qemu-devel@nongnu.org; Wed, 06 May 2009 13:36:44 -0400
Received: from mx2.redhat.com ([66.187.237.31]:37889)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <glommer@redhat.com>) id 1M1l2y-0002IJ-I3
	for qemu-devel@nongnu.org; Wed, 06 May 2009 13:36:44 -0400
Date: Wed, 6 May 2009 14:41:36 -0300
From: Glauber Costa <glommer@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH 2/4] move CPUID_APIC flag to where it
	belongs
Message-ID: <20090506174136.GG26401@poweredge.glommer>
References: <1241621382-21577-1-git-send-email-glommer@redhat.com>
	<1241621382-21577-2-git-send-email-glommer@redhat.com>
	<1241621382-21577-3-git-send-email-glommer@redhat.com>
	<4A01AF78.7050102@siemens.com>
	<20090506155141.GE26401@poweredge.glommer>
	<000001c9ce70$3416d3a0$9c447ae0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000001c9ce70$3416d3a0$9c447ae0$@com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stanislav <stlintel@gmail.com>
Cc: 'Jan Kiszka' <jan.kiszka@siemens.com>, aliguori@us.ibm.com, qemu-devel@nongnu.org

On Wed, May 06, 2009 at 08:29:23PM +0300, Stanislav wrote:
> If OS boot fine its more luck. The flag indicates presence of local apic,
> not "if it is supported".
> For example when lapic is globally disabled (i.e. not present) CPUID flag is
> cleared off as well.
> But CPU is still supports lapic, after reset it will be back.
What if we take out a cpu that supports lapic, and is connected to an apic system,
and connects it to a board that has no apic?

Also, note that in the old code, it was set regardless of the existance of an APIC
anyway. The only dependancy was on smp_cpus > 1.