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

RE: [Xen-devel] [PATCH]ACPI: workaround for S3 fail in two facs tables

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH]ACPI: workaround for S3 fail in two facs tables case
From: "Wei, Gang" <gang.wei@xxxxxxxxx>
Date: Fri, 26 Feb 2010 09:43:01 +0800
Accept-language: zh-CN, en-US
Acceptlanguage: zh-CN, en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 25 Feb 2010 17:43:45 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B86452C020000780003136C@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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E6467867A6B05E4FA831B7DF29925F5C40BBA48B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B86452C020000780003136C@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acq19fv2yUjoSyuYRhurqDgEnIQMjgAjNOfg
Thread-topic: [Xen-devel] [PATCH]ACPI: workaround for S3 fail in two facs tables case
Jan Beulich wrote:
>>>> "Wei, Gang" <gang.wei@xxxxxxxxx> 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@xxxxxxxxx>
>> 
> 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?

ACPI 4.0 required that if Xfacs is non-zero facs should be zero. Pointed by 
either Xfacs or facs, the FACS table should be the same. The major reason using 
Xfacs should be just making FACS capable to be located above 4GB. To be 
pre-2.0-OS compatible a BIOS is better to allocate the FACS table under 4GB and 
pass the single address in both facs & Xfacs.

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