From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH] Set bit 1 in disabled processor's _STA Date: Mon, 18 May 2009 08:53:58 +0300 Message-ID: <20090518055358.GA6438@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Glauber Costa , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:42687 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753112AbZERFx7 (ORCPT ); Mon, 18 May 2009 01:53:59 -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 n4I5s0cU032431 for ; Mon, 18 May 2009 01:54:00 -0400 Content-Disposition: inline In-Reply-To: <4A10F5D6.5060700@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. Interesting whether _OSI(Windows) will evaluate to TRUE on Linux. -- Gleb.