Re: [PATCH]ACPI: workaround for S3 fail in two facs tables case

["Jan Beulich" <JBeulich@novell.com>]

>>> "Wei, Gang" <gang.wei@intel.com> 25.02.10 06:49 >>>
>ACPI: workaround for S3 fail in two facs tables case
>
>Some legacy BIOS which support ACPI2.0+ may expose two FACS tables via both FADT->FIRMWARE_CTRL and FADT->X_FIRMWARE_CTRL, but only lookup S3 waking_vector in the first one. So enhance the X_FIRMWARE_CTRL selection condition by adding FADT->FIRMWARE_CTRL == 0.
>
>Signed-off-by: Wei Gang <gang.wei@intel.com>
>
>diff -r e11c8dcbf690 xen/arch/x86/acpi/boot.c
>--- a/xen/arch/x86/acpi/boot.c	Wed Feb 24 11:00:11 2010 +0800
>+++ b/xen/arch/x86/acpi/boot.c	Thu Feb 25 20:47:37 2010 +0800
>@@ -365,7 +365,7 @@ acpi_fadt_parse_sleep_info(struct acpi_t
> 	       acpi_sinfo.pm1b_evt_blk.address);
> 
> 	/* Now FACS... */
>-	if (fadt->header.revision >= FADT2_REVISION_ID)
>+	if (fadt->header.revision >= FADT2_REVISION_ID && fadt->facs == 0)
> 		facs_pa = fadt->Xfacs;
> 	else
> 		facs_pa = (uint64_t)fadt->facs;

Wouldn't that generally suppress using fadt->Xfacs, since I think in
order to be pre-2.0-OS compatible a BIOS would not normally set
facs to zero when Xfacs is non-zero? Or is that a requirement by the
spec?

Jan