Enable _OSI(Linux) for Xen HVM domains

PATCH In review Alex Williamson 2 participants 3 messages Nov 6, 2007 – Jan 17, 2008 ACPI

Share & tools

Alex Williamson

author

2007-11-06 19:31 UTC #0 lore raw

PATCH 1/1 Enable _OSI(Linux) for Xen HVM domains

I'd like to enable _OSI(Linux) for Xen HVM domains. As I understand
it, the main reason for disabling _OSI(Linux) by default is to avoid dealing with a myriad of systems with broken Linux code paths in their BIOS (while we know the Windows code path is functional). With fully virtualized Xen domains, the "BIOS" code is provided from the Xen project (or separate open source tree in the case on ia64). We can therefore verify the Linux code path works and we can take advantage of the _OSI call to make optimization in the hypervisor based on the guest's response. The patch below enables this feature on both x86 and ia64 Xen via the existing DMI hook. Thanks,

Alex

Signed-off-by Alex Williamson <[email protected]>

Acked-by Keir Fraser <[email protected]>

drivers/acpi/osl.c +8 -0

diff -r c7f1be4e5832 drivers/acpi/osl.c
@@ -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 */

Len Brown

reviewer

2008-01-17 00:59 UTC #1 lore raw

Quoted 28 lines · Alex Williamson

I'd like to enable _OSI(Linux) for Xen HVM domains. As I understand
it, the main reason for disabling _OSI(Linux) by default is to avoid dealing with a myriad of systems with broken Linux code paths in their BIOS (while we know the Windows code path is functional). With fully virtualized Xen domains, the "BIOS" code is provided from the Xen project (or separate open source tree in the case on ia64). We can therefore verify the Linux code path works and we can take advantage of the _OSI call to make optimization in the hypervisor based on the guest's response. The patch below enables this feature on both x86 and ia64 Xen via the existing DMI hook. Thanks,
Alex
Signed-off-by Alex Williamson <[email protected]>
Acked-by Keir Fraser <[email protected]>
--
diff -r c7f1be4e5832 drivers/acpi/osl.c
drivers/acpi/osl.c +1 -0
@@ -1225,6 +1225,14 @@ static struct dmi_system_id acpi_osl_dmi
 		     DMI_MATCH(DMI_BOARD_NAME, "MPAD-MSAE Customer Reference Boards"),
 		     },
 	 },
+	{

drivers/acpi/osl.c static struct dmi_system_id acpi_osl_dmi · line 1238

Quoted 10 lines

drivers/acpi/osl.c +7 -0

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

Hi Alex,

I think it is fine for the "BIOS" to use the OSI mechanism to ask about the OS. However, the string "Linux" is probably not a good choice for the string.

The reason we deleted OSI(Linux) by default is because it is ill-defined. A good OSI string would be much more specific, ie. label something that is well defined, or at least include version information.

eg. "ACPI 3.0 Thermal Model" means that an OS implements the ACPI 3.0 extensions to the thermal model (which we don't, BTW).

The problem with "Linux" is that
A. it is usually used by mistake, inherited from the Intel
reference BIOS which unfortunately referenced it. Sometimes it does things like disable the HPET -- totally random.

B. it is used on purpose, but for reasons that
may not be valid in all versions of Linux. eg. the enabling S3 video re-post on resume. This is very snappy, until you have a native Linux graphics device driver than can do it in a fraction of the time... etc.

so if you're looking at a specific property of the OS, it would be better to build that string into the OS -- giving you the option to no longer build in that string if that specific property changes in a different version...

thanks,
-Len

Alex Williamson

author

2008-01-17 22:16 UTC #2 lore raw

Quoted 10 lines · Len Brown

I think it is fine for the "BIOS" to use the OSI mechanism to ask about the OS. However, the string "Linux" is probably not a good choice for the string.
The reason we deleted OSI(Linux) by default is because it is ill-defined. A good OSI string would be much more specific, ie. label something that is well defined, or at least include version information.
eg. "ACPI 3.0 Thermal Model" means that an OS implements the ACPI 3.0 extensions to the thermal model (which we don't, BTW).

Hi Len,

Thanks for the extra explanation. For now, we've decided to go a
different route and create a domain configuration option, so we can do without this patch. Thanks,

Alex

Signature · 1 line

Alex Williamson                             HP Open Source & Linux Org.