From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Z1M-0001iY-4x for qemu-devel@nongnu.org; Tue, 21 Jan 2014 05:57:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5Z1F-0000mt-SE for qemu-devel@nongnu.org; Tue, 21 Jan 2014 05:57:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:15906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Z1F-0000mk-IZ for qemu-devel@nongnu.org; Tue, 21 Jan 2014 05:57:21 -0500 Date: Tue, 21 Jan 2014 13:02:02 +0200 From: "Michael S. Tsirkin" Message-ID: <20140121110202.GA22693@redhat.com> References: <20140120212517.GD18508@ERROL.INI.CMU.EDU> <52DE4CDC.4070501@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52DE4CDC.4070501@redhat.com> Subject: Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: imammedo@redhat.com, "Gabriel L. Somlo" , lersek@redhat.com, qemu-devel@nongnu.org, agraf@suse.de On Tue, Jan 21, 2014 at 11:33:00AM +0100, Paolo Bonzini wrote: > 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. Exactly, I read it that way too. > 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. Insane, yes. This is however what windows does and this is what microsoft document explicitly says. > 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 We restrict ourselves to a very small subset of the spec that seems to work well everywhere, and so far OSPMs seem to assume that's what no _OSI means. -- MST