From: Alex Williamson <alex.williamson@hp.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [RFC] Enable _OSI(Linux) for Xen HVM domains
Date: Tue, 06 Nov 2007 10:00:34 -0700 [thread overview]
Message-ID: <1194368434.31834.146.camel@bling> (raw)
I'd like to send this patch to upstream lkml/linux-acpi, but I want to
make sure that the x86 side wants this too. The _OSI method is a way
for platform ACPI firmware to determine the features and capabilities of
the OS running on the system. This is usually done by calling the _OSI
method with various strings in the _INI method of an ACPI device. The
strings are things like "Linux" or "Windows". ACPI may set internal
variables and adjust code paths based on the ACPI compatibility reported
by this method. The act of ack'ing or nak'ing an OS compatibility is
the job of the OSL layer.
Until recent Linux kernel versions, Linux would respond true to both
"Linux" and "Windows", indicating the ACPI layers are compatible with
both. Recent version of Linux no longer respond true by default to
_OSI(Linux) calls. The idea is that most BIOS vendors consider Linux an
after thought. The few that do check for Linux compatibility probably
don't test those code paths nearly as well for Linux as they do for
Windows. Therefore, rather than fight broken ACPI, it's easier to only
report Windows compatibility and have a known good code path through the
BIOS code, and fix the Linux ACPI subsystem where needed.
Things are a bit different for Xen HVM domains. Both the OS and the
BIOS code are open source, and (IMHO) there's no reason a Linux guest
shouldn't acknowledge Linux compatibility when running on Xen. On ia64,
we're actually using this information to make some optimizations in the
hypervisor for handling the guest. The mechanism to enable a positive
response to _OSI(Linux) is a simple DMI hook with fields generated from
the SMBIOS table, which both x86 and ia64 Xen provide to HVM domains.
Please let me know if there are any comments or objections to submitting
this upstream. Thanks,
Alex
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
--
diff -r c7f1be4e5832 drivers/acpi/osl.c
--- a/drivers/acpi/osl.c Thu Nov 01 12:09:33 2007 -0700
+++ b/drivers/acpi/osl.c Fri Nov 02 15:30:23 2007 -0700
@@ -1225,6 +1225,14 @@ static struct dmi_system_id acpi_osl_dmi
DMI_MATCH(DMI_BOARD_NAME, "MPAD-MSAE Customer Reference Boards"),
},
},
+ {
+ .callback = dmi_osi_linux,
+ .ident = "Xen HVM domU",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Xen"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HVM domU"),
+ },
+ },
{}
};
#endif /* CONFIG_DMI */
next reply other threads:[~2007-11-06 17:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-06 17:00 Alex Williamson [this message]
2007-11-06 17:18 ` [RFC] Enable _OSI(Linux) for Xen HVM domains Keir Fraser
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=1194368434.31834.146.camel@bling \
--to=alex.williamson@hp.com \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.