* [PATCH] Enable _OSI(Linux) for Xen HVM domains
@ 2007-11-06 19:05 Alex Williamson
2008-01-17 0:44 ` Len Brown
0 siblings, 1 reply; 3+ messages in thread
From: Alex Williamson @ 2007-11-06 19:05 UTC (permalink / raw)
To: Len Brown; +Cc: linux-acpi, Keir Fraser
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 <alex.williamson@hp.com>
Acked-by: Keir Fraser <keir@xensource.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 */
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Enable _OSI(Linux) for Xen HVM domains
2007-11-06 19:05 [PATCH] Enable _OSI(Linux) for Xen HVM domains Alex Williamson
@ 2008-01-17 0:44 ` Len Brown
2008-01-17 22:15 ` Alex Williamson
0 siblings, 1 reply; 3+ messages in thread
From: Len Brown @ 2008-01-17 0:44 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-acpi, Keir Fraser
On Tuesday 06 November 2007 14:05, Alex Williamson wrote:
>
> 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 <alex.williamson@hp.com>
> Acked-by: Keir Fraser <keir@xensource.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 */
>
>
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Enable _OSI(Linux) for Xen HVM domains
2008-01-17 0:44 ` Len Brown
@ 2008-01-17 22:15 ` Alex Williamson
0 siblings, 0 replies; 3+ messages in thread
From: Alex Williamson @ 2008-01-17 22:15 UTC (permalink / raw)
To: Len Brown; +Cc: linux-acpi, Keir Fraser
On Wed, 2008-01-16 at 19:44 -0500, Len Brown wrote:
>
> 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
--
Alex Williamson HP Open Source & Linux Org.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-01-17 22:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-06 19:05 [PATCH] Enable _OSI(Linux) for Xen HVM domains Alex Williamson
2008-01-17 0:44 ` Len Brown
2008-01-17 22:15 ` Alex Williamson
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).