From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Gabriel L. Somlo" <gsomlo@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
agraf@suse.de, lersek@redhat.com, qemu-devel@nongnu.org,
imammedo@redhat.com
Subject: Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP
Date: Mon, 20 Jan 2014 22:31:56 +0200 [thread overview]
Message-ID: <20140120203156.GB14528@redhat.com> (raw)
In-Reply-To: <20140120185414.GC18508@ERROL.INI.CMU.EDU>
On Mon, Jan 20, 2014 at 01:54:15PM -0500, Gabriel L. Somlo wrote:
> On Mon, Jan 20, 2014 at 01:16:02PM +0100, Paolo Bonzini wrote:
> > Il 20/01/2014 13:08, Michael S. Tsirkin ha scritto:
> > >>> > > I think the hack looking for the SMC device is safer than _OSI: OSPMs
> > >>> > > are known to do crazy things when they see _OSI, such as assuming they
> > >>> > > need to try and emulate the OS probed.
> >
> > Source for "OSPMs do crazy things when they see _OSI".
>
> After a bit more digging, I believe this has to do with the fact that
> OSPM is responsible for define _OSI, and referencing it from e.g. the
> HPET._CRS method when it's NOT defined (e.g. by a misbehaving OSPM)
> results in all sorts of unpleasantness.
No, that's not what I meant.
Responded to the original question with what my
real concern was.
> In fact, looking on the MacBookPro, we see the following:
>
> DefinitionBlock ("dsdt.aml", "DSDT", 1, "APPLE ", "MacBookP", 0x00090001)
> {
> ...
> Field (GNVS, AnyAcc, Lock, Preserve) {
> OSYS, 16,
> ...
> }
> ...
> Scope (\_SB) {
> Method (_INI, 0, NotSerialized) {
> Store (0x07DC, OSYS)
> If (CondRefOf (\_OSI, Local0)) {
> If (_OSI ("Darwin")) {
> Store (0x2710, OSYS)
> }
> If (\_OSI ("Linux")) {
> Store (0x03E8, OSYS)
> }
> If (\_OSI ("Windows 2009")) {
> Store (0x07D9, OSYS)
> }
> If (\_OSI ("Windows 2012")) {
> Store (0x07DC, OSYS)
> }
> }
> }
> ...
> }
> ...
>
> So, basically, they give OSYS a default value, then *if* _OSI is
> defined by a well-behaved OSPM, they use it to give OSYS a more
> useful, specific value. CondRefOf is used to avoid a fatal error
> in case _OSI does not exist.
Good to know, thanks for the info.
> And later:
>
> Device (HPET) {
> Name (_HID, EisaId ("PNP0103"))
> Name (_CID, EisaId ("PNP0C01"))
> Name (BUF0, ResourceTemplate () {
> IRQNoFlags () {0}
> IRQNoFlags () {8}
> Memory32Fixed (ReadWrite,
> 0xFED00000, // Address Base
> 0x00000400, // Address Length
> _Y16)
> })
> Method (_STA, 0, NotSerialized) {
> If (LGreaterEqual (OSYS, 0x07D1)) {
> If (HPAE) {
> Return (0x0F)
> }
> } Else {
> If (HPAE) {
and where does HPAE come from?
> Return (0x0B)
> }
> }
> Return (0x00)
> }
> ...
> }
>
> Which begins to explain why, on the MBP2,2 I didn't see the HPET show
> up in the XP device tree at all ! :)
>
> I.e., I wonder if XP actually defines _OSI (my inner gambling addict
> says it probably does not).
This document says it does:
http://msdn.microsoft.com/library/windows/hardware/gg463275
> Long story short, we could use CondRefOf as an intermediary wrapper
> around _OSI to avoid referencing SMC._STA from within HPET.CRS...
I'm not sure why it's a problem to refer to SMC._STA
but if it is, we can just patch in another variable
in the HPET scope instead of _OSI.
> Not sure we want to "complicate" the rest of the HPET (e.g. return
> different values for bit2, "show device in acpi u/i" depending on
> _OSI, the way Apple machines do).
>
> Thanks,
> --Gabriel
They seem to clear this bit for linux?
No idea why they do this - want to try looking into
linux source to figure out?
--
MST
next prev parent reply other threads:[~2014-01-20 20:27 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-08 20:02 [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386 Gabriel L. Somlo
2014-01-08 20:38 ` Michael S. Tsirkin
2014-01-08 21:09 ` Gabriel L. Somlo
2014-01-15 11:13 ` Paolo Bonzini
2014-01-08 22:13 ` Paolo Bonzini
2014-01-08 23:39 ` Gabriel L. Somlo
2014-01-09 0:12 ` Alexander Graf
2014-01-09 1:51 ` Michael S. Tsirkin
2014-01-09 18:51 ` Gabriel L. Somlo
2014-01-09 20:12 ` Paolo Bonzini
2014-01-09 21:33 ` Michael S. Tsirkin
2014-01-09 21:58 ` Gabriel L. Somlo
2014-01-09 21:44 ` Gabriel L. Somlo
2014-01-10 12:37 ` Paolo Bonzini
2014-01-10 15:35 ` Gabriel L. Somlo
2014-01-10 16:13 ` Igor Mammedov
2014-01-17 21:10 ` [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP Gabriel L. Somlo
2014-01-20 11:58 ` Michael S. Tsirkin
2014-01-20 11:57 ` Paolo Bonzini
2014-01-20 12:08 ` Michael S. Tsirkin
2014-01-20 12:16 ` Paolo Bonzini
2014-01-20 18:54 ` Gabriel L. Somlo
2014-01-20 20:31 ` Michael S. Tsirkin [this message]
2014-01-20 21:25 ` Gabriel L. Somlo
2014-01-21 10:33 ` Paolo Bonzini
2014-01-21 11:02 ` Michael S. Tsirkin
2014-01-21 11:05 ` Paolo Bonzini
2014-01-21 11:44 ` Michael S. Tsirkin
2014-01-21 18:11 ` [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X Gabriel L. Somlo
2014-01-21 18:38 ` Michael S. Tsirkin
2014-01-24 16:46 ` Gabriel L. Somlo
2014-01-24 21:18 ` Alexander Graf
2014-01-25 0:09 ` Gabriel L. Somlo
2014-01-25 9:08 ` Alexander Graf
2014-01-27 22:51 ` Gabriel L. Somlo
2014-01-27 23:51 ` Alexander Graf
2014-01-28 16:45 ` [Qemu-devel] OSX guest support review Gabriel L. Somlo
2014-01-28 16:57 ` Michael S. Tsirkin
2014-01-29 14:17 ` Alexander Graf
2014-01-29 21:36 ` [Qemu-devel] OSX guest vs. kvm ioapic polarity Gabriel L. Somlo
2014-01-29 22:18 ` Michael S. Tsirkin
2014-01-30 14:18 ` Gabriel L. Somlo
2014-01-30 19:48 ` Michael S. Tsirkin
2014-01-30 20:21 ` Gabriel L. Somlo
2014-01-30 20:28 ` Michael S. Tsirkin
2014-01-30 20:33 ` Michael S. Tsirkin
2014-01-30 20:44 ` Gabriel L. Somlo
2014-02-11 18:23 ` [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest Gabriel L. Somlo
2014-02-11 19:54 ` Michael S. Tsirkin
2014-02-11 21:35 ` Gabriel L. Somlo
2014-02-14 21:13 ` Gabriel L. Somlo
2014-02-14 21:21 ` Alexander Graf
2014-02-14 22:06 ` Gabriel L. Somlo
2014-02-14 22:13 ` Alexander Graf
2014-02-16 11:18 ` Michael S. Tsirkin
2014-02-16 11:41 ` Michael S. Tsirkin
2014-02-16 14:47 ` Alex Williamson
2014-02-16 16:23 ` Michael S. Tsirkin
2014-02-17 17:57 ` Gabriel L. Somlo
2014-02-17 18:01 ` Gabriel L. Somlo
2014-02-17 18:06 ` Paolo Bonzini
2014-02-17 19:38 ` Gabriel L. Somlo
2014-02-18 0:58 ` Gabriel L. Somlo
2014-02-27 17:05 ` [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity Michael S. Tsirkin
2014-02-27 21:41 ` Gabriel L. Somlo
2014-02-27 22:30 ` Paolo Bonzini
2014-02-27 23:13 ` Gabriel L. Somlo
2014-02-27 23:31 ` Paolo Bonzini
2014-02-28 4:06 ` [Qemu-devel] [RFC PATCH v2] kvm: x86: ignore ioapic polarity Gabriel L. Somlo
2014-02-28 17:23 ` [Qemu-devel] [RFC PATCH] qemu: " Gabriel L. Somlo
2014-02-28 18:57 ` [Qemu-devel] [RFC PATCH v2] " Gabriel L. Somlo
2014-02-28 19:14 ` [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11 Gabriel L. Somlo
2014-03-01 3:44 ` Alexander Graf
2014-03-01 4:25 ` Gabriel L. Somlo
2014-03-01 5:45 ` Alexander Graf
2014-03-01 14:46 ` Paolo Bonzini
2014-03-02 0:17 ` Gabriel L. Somlo
2014-03-02 8:56 ` Paolo Bonzini
2014-03-02 14:31 ` Michael S. Tsirkin
2014-03-02 16:02 ` Michael S. Tsirkin
2014-03-06 7:50 ` Michael S. Tsirkin
2014-03-02 14:52 ` [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity Michael S. Tsirkin
2014-03-02 16:15 ` Gabriel L. Somlo
2014-03-02 17:09 ` Michael S. Tsirkin
2014-03-06 7:45 ` Michael S. Tsirkin
2014-03-02 14:55 ` [Qemu-devel] [RFC PATCH v2] kvm: " Michael S. Tsirkin
2014-03-13 10:53 ` Paolo Bonzini
2014-03-13 13:43 ` Gabriel L. Somlo
2014-02-28 4:55 ` [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity Michael S. Tsirkin
2014-02-28 8:10 ` Paolo Bonzini
2014-02-28 8:11 ` Paolo Bonzini
2014-03-01 5:03 ` Alex Williamson
2014-02-16 11:34 ` [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest Michael S. Tsirkin
2014-02-16 15:12 ` Peter Maydell
2014-02-16 11:37 ` Michael S. Tsirkin
2014-01-29 23:13 ` [Qemu-devel] OSX guest vs. kvm ioapic polarity Alexander Graf
2014-01-30 15:56 ` Gabriel L. Somlo
2014-01-28 20:40 ` [Qemu-devel] osx bootloader Gabriel L. Somlo
2014-01-28 22:51 ` BALATON Zoltan
2014-01-29 3:07 ` Gabriel L. Somlo
2014-01-29 11:29 ` BALATON Zoltan
2014-01-29 14:53 ` Gabriel L. Somlo
2014-01-29 15:00 ` Alexander Graf
2014-01-30 0:15 ` BALATON Zoltan
2014-02-01 17:43 ` BALATON Zoltan
2014-02-01 0:38 ` BALATON Zoltan
2014-02-01 10:07 ` Alexander Graf
2014-02-01 14:35 ` [Qemu-devel] OVMF with q35 (was: osx bootloader) BALATON Zoltan
2014-02-01 15:13 ` Alexander Graf
2014-02-01 17:38 ` BALATON Zoltan
2014-02-03 7:47 ` Gerd Hoffmann
2014-02-01 21:19 ` [Qemu-devel] osx bootloader Paolo Bonzini
2014-02-02 2:18 ` BALATON Zoltan
2014-01-29 12:10 ` BALATON Zoltan
2014-01-29 14:20 ` Alexander Graf
2014-01-21 11:38 ` [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP Michael S. Tsirkin
2014-01-20 20:23 ` Michael S. Tsirkin
2014-01-20 12:03 ` Igor Mammedov
2014-01-09 8:46 ` [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386 Markus Armbruster
2014-01-09 10:24 ` Paolo Bonzini
2014-01-31 19:03 ` [Qemu-devel] [RFC PATCH v2] Add option to switch off FDC Gabriel L. Somlo
2014-01-31 19:39 ` Eric Blake
2014-02-02 13:47 ` Michael S. Tsirkin
2014-02-10 14:10 ` Marcel Apfelbaum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140120203156.GB14528@redhat.com \
--to=mst@redhat.com \
--cc=agraf@suse.de \
--cc=gsomlo@gmail.com \
--cc=imammedo@redhat.com \
--cc=lersek@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).