From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLT52-0007FI-KG for qemu-devel@nongnu.org; Thu, 06 Mar 2014 02:51:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLT4x-00041a-NT for qemu-devel@nongnu.org; Thu, 06 Mar 2014 02:51:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLT4x-00041U-E6 for qemu-devel@nongnu.org; Thu, 06 Mar 2014 02:50:55 -0500 Date: Thu, 6 Mar 2014 09:50:48 +0200 From: "Michael S. Tsirkin" Message-ID: <20140306075048.GA3267@redhat.com> References: <20140228185719.GJ17184@ERROL.INI.CMU.EDU> <20140228191425.GK17184@ERROL.INI.CMU.EDU> <5311F2BE.4060206@redhat.com> <20140302001707.GO17184@ERROL.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140302001707.GO17184@ERROL.INI.CMU.EDU> Subject: Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: Paolo Bonzini , qemu-devel@nongnu.org, agraf@suse.de On Sat, Mar 01, 2014 at 07:17:07PM -0500, Gabriel L. Somlo wrote: > On Sat, Mar 01, 2014 at 03:46:22PM +0100, Paolo Bonzini wrote: > > Il 28/02/2014 20:14, Gabriel L. Somlo ha scritto: > > >Some guests (e.g. 0S X) insist on a minimum lapic version of 0x14. > > >This patch bumps the emulated lapic version to 0x14 to accomodate that. > > > > > >Signed-off-by: Gabriel L. Somlo > > > > Looks good, but you have to make this a qdev property so that older > > versions keep using version 0x11. > > After digging around a bit, I think adding a "uint8_t lapic_version" > member to to "struct x86_def_t" might be even better, as the version > is pretty much a property of the on-chip local APIC, not necessarily > something best left up to the user... > > It could default to 0x11 for anything purely virtual (e.g. qemu64, > kvm64, etc.) and to the appropriate value for chips with a real-world > physical correspondent (core2duo, haswell, westmere, etc) > > > Although, on KVM, it's simply hardcoded to 0x14 rather than exposing to > the guest whatever the host CPU's apic version happens to be, or > trying to match it to the CPU model: > > > [somlo@foober kvm]$ grep -i version arch/x86/kvm/lapic.c > ... > /* 14 is the version for Xeon and Pentium 8.4.8*/ > #define APIC_VERSION (0x14UL | ((APIC_LVT_NUM - 1) << 16)) > ... > > > I'd honestly prefer to stick to 0x14 (because it's simple :) ) but if > you're sure that's a bad idea, how about the struct x86_def_t rather > than qdev ? > > So far, only OS X seems to even care at all about the version... > > Thanks, > --Gabriel No, your patch is fine generally, it's not about users tweaking the version. It's about users getting compatible behaviour when they specify e.g. -M pc-1.6 Using property here is an implementation detail not exposed to users. Look for all the PC_COMPAT macros as an example of that. -- MST