From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Set bit 1 in disabled processor's _STA Date: Mon, 18 May 2009 08:44:54 +0300 Message-ID: <4A10F5D6.5060700@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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Glauber Costa , kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mx2.redhat.com ([66.187.237.31]:46298 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750706AbZERFox (ORCPT ); Mon, 18 May 2009 01:44:53 -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 n4I5itOW030058 for ; Mon, 18 May 2009 01:44:55 -0400 In-Reply-To: <20090518051718.GL3909@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.