From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH] Set bit 1 in disabled processor's _STA Date: Mon, 18 May 2009 08:39:43 -0300 Message-ID: <20090518113943.GR27295@poweredge.glommer> References: <1242389683-12967-1-git-send-email-glommer@redhat.com> <20090517082347.GG3909@redhat.com> <20090517143107.GM27295@poweredge.glommer> <20090517143235.GK3909@redhat.com> <20090517150727.GO27295@poweredge.glommer> <20090517153022.GB21386@redhat.com> <4A106E83.6080302@redhat.com> <20090518051718.GL3909@redhat.com> <4A10F5D6.5060700@redhat.com> <20090518055358.GA6438@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mx2.redhat.com ([66.187.237.31]:38604 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbZERLeh (ORCPT ); Mon, 18 May 2009 07:34:37 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n4IBYcZo012752 for ; Mon, 18 May 2009 07:34:38 -0400 Content-Disposition: inline In-Reply-To: <20090518055358.GA6438@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, May 18, 2009 at 08:53:58AM +0300, Gleb Natapov wrote: > On Mon, May 18, 2009 at 08:44:54AM +0300, Avi Kivity wrote: > > Gleb Natapov wrote: > >> On Sun, May 17, 2009 at 11:07:31PM +0300, Avi Kivity wrote: > >> > >>> Gleb Natapov wrote: > >>> > >>>> Theoretically we can provide different values for different OSes, but > >>>> this is just a guess work since there is no any documentation how CPU > >>>> hot-plug should work on x86. > >>>> > >>> ACPI in fact supports this, but I hope we don't have to do that. > >>> > >>> > >> ACPI way is what I am talking about. Implement _OS object. > >> > > > > /* > > * The story of _OSI(Linux) > > * > > * From pre-history through Linux-2.6.22, > > * Linux responded TRUE upon a BIOS OSI(Linux) query. > > * > > * Unfortunately, reference BIOS writers got wind of this > > * and put OSI(Linux) in their example code, quickly exposing > > * this string as ill-conceived and opening the door to > > * an un-bounded number of BIOS incompatibilities. > > * > > * For example, OSI(Linux) was used on resume to re-POST a > > * video card on one system, because Linux at that time > > * could not do a speedy restore in its native driver. > > * But then upon gaining quick native restore capability, > > * Linux has no way to tell the BIOS to skip the time-consuming > > * POST -- putting Linux at a permanent performance disadvantage. > > * On another system, the BIOS writer used OSI(Linux) > > * to infer native OS support for IPMI! On other systems, > > * OSI(Linux) simply got in the way of Linux claiming to > > * be compatible with other operating systems, exposing > > * BIOS issues such as skipped device initialization. > > * > > * So "Linux" turned out to be a really poor chose of > > * OSI string, and from Linux-2.6.23 onward we respond FALSE. > > * > > * BIOS writers should NOT query _OSI(Linux) on future systems. > > * Linux will complain on the console when it sees it, and return FALSE. > > * To get Linux to return TRUE for your system will require > > * a kernel source update to add a DMI entry, > > * or boot with "acpi_osi=Linux" > > */ > > > > // Looks like no real content in this message? > > > Now I recall something on LKML about this. Well, in this case Linux > shouldn't have used ACPI to invent its own way to do cpu hot-plug. It didn't. History shows that this method is what is used in some unisys machines, which seems to be the only ones implementing this around.