From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: L1[0x1fb] = 0000000000000000 which faults on one type of machine but on another works? Date: Thu, 17 Mar 2011 10:21:37 -0700 Message-ID: <4D824321.6010206@goop.org> References: <20110316221912.GA13035@dumpdata.com> <4D81EF97020000780003706E@vpn.id2.novell.com> <20110317155211.GA29603@dumpdata.com> <4D82411002000078000371D8@vpn.id2.novell.com> <20110317164143.GA26392@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110317164143.GA26392@dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com, andrew.thomas@oracle.com, Jan Beulich , Ian Campbell , keir.xen@gmail.com, swente@infinitumb.de, gianni.tedesco@citrix.com List-Id: xen-devel@lists.xenproject.org On 03/17/2011 09:41 AM, Konrad Rzeszutek Wilk wrote: > I don't remember if it was suggested to hpa/ingo/tglx whether we could > provide another 'struct apic' that would be Xen specific and the apic->probe() > would either provide a struct mostly filled with dummy functions that return > nothing, or the Xen apic->probe() function would over-write the current > 'apic->read,write, etc' with the xen dummy functions. I still maintain the "proper fix" is to just turn off the APIC CPU capability. There is no local apic, and trying to pretend otherwise just leads to a mass of hacks. But of course, that's not particularly easy in practice... J