From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Ydt-0000mh-Sm for qemu-devel@nongnu.org; Tue, 21 Jan 2014 05:33:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5Ydn-0000wP-Qp for qemu-devel@nongnu.org; Tue, 21 Jan 2014 05:33:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Ydn-0000wA-JO for qemu-devel@nongnu.org; Tue, 21 Jan 2014 05:33:07 -0500 Message-ID: <52DE4CDC.4070501@redhat.com> Date: Tue, 21 Jan 2014 11:33:00 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20140120212517.GD18508@ERROL.INI.CMU.EDU> In-Reply-To: <20140120212517.GD18508@ERROL.INI.CMU.EDU> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: imammedo@redhat.com, agraf@suse.de, lersek@redhat.com, qemu-devel@nongnu.org, "Michael S. Tsirkin" Il 20/01/2014 22:25, Gabriel L. Somlo ha scritto: > > "Implementation Note > Place the routine that identifies the operating system in an _INI method > under the \_SB scope so that _OSI can run as early as possible. This > placement is important because the operating system makes features > available based on the string argument to the _OSI method." > > It all depends on what the document's author meant by "the operating > system" which "makes features available". Because somewhere earlier in > the document they say: > > "Recent versions of the ACPI spec have extended the use cases of > the _OSI method beyond host operating system version identification. > However, Windows supports _OSI only for the use of identifying the host > version of Windows that is running on the system." I read that as referring to things like _OSI("3.0 Thermal Model"). It means (the way I read it) that Windows will not publish that kind of _OSI string. I think it is safe to assume that no OSPM will do those crazy things with OS-defined _OSI strings (it's quite plausible that they do it with feature _OSI strings). First, because IMHO it is completely insane. Second, because the current DSDT would also be theoretically broken with an OSPM that does strange things with _OSI. We never call _OSI, so the OSPM could presume that it should "disable all features". Paolo