qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP
Date: Tue, 21 Jan 2014 13:02:02 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]