WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [RFC] Enable _OSI(Linux) for Xen HVM domains

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [RFC] Enable _OSI(Linux) for Xen HVM domains
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Tue, 06 Nov 2007 10:00:34 -0700
Delivery-date: Tue, 06 Nov 2007 09:01:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: HP OSLO R&D
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
  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@xxxxxx>
--

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 */



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>