Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1171002 > unrolled thread

Re: [PATCH 03/32] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 03/32] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS. "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-06-24 02:10 +0200
    RE: [PATCH 03/32] ACPICA: Hardware: Enable 64-bit firmware waking  vector for selected FACS. "Zheng, Lv" <lv.zheng@intel.com> - 2015-06-24 02:20 +0200

#1171002 — Re: [PATCH 03/32] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

On Friday, June 19, 2015 11:38:28 AM Lv Zheng wrote:
> ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4
> 
> The root cause of the reported bug might be one of the followings:
> 1. BIOS may favor the 64-bit firmware waking vector address when the
>    version of the FACS is greater than 0 and Linux currently only supports
>    resuming from the real mode, so the 64-bit firmware waking vector has
>    never been set and might be invalid to BIOS while the commit enables
>    higher version FACS.
> 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
>    FADT while the commit doesn't set the firmware waking vector address of
>    the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
>    vector address of the FACS reported by "X_FIRMWARE_CTRL".
> 
> This patch excludes the cases that can trigger the bugs caused by the root
> cause 1.
> 
> ACPI specification says:
> A. 32-bit FACS address (FIRMWARE_CTRL field in FADT):
>    Physical memory address of the FACS, where OSPM and firmware exchange
>    control information.
>    If the X_FIRMWARE_CTRL field contains a non zero value then this field
>    must be zero.
>    A zero value indicates that no FACS is specified by this field.
> B. 64-bit FACS address (X_FIRMWARE_CTRL field in FADT):
>    64bit physical memory address of the FACS.
>    This field is used when the physical address of the FACS is above 4GB.
>    If the FIRMWARE_CTRL field contains a non zero value then this field
>    must be zero.
>    A zero value indicates that no FACS is specified by this field.
> Thus the 32bit and 64bit firmware waking vector should indicate completely
> different resuming environment - real mode (1MB addressable) and non real
> mode (4GB+ addressable) and currently Linux only supports resuming from
> real mode.
> 
> This patch enables 64-bit firmware waking vector for selected FACS via
> acpi_set_firmware_waking_vector() so that it's up to OSPMs to determine which
> resuming mode should be used by BIOS and ACPICA changes won't trigger the
> bugs caused by the root cause 1. For example, Linux can pass
> physical_address64=0 as the parameter of acpi_set_firmware_waking_vector() to
> indicate no 64bit waking vector support. Lv Zheng.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
> Link: https://github.com/acpica/acpica/commit/7aa598d7
> Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org>
> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
> Signed-off-by: Bob Moore <robert.moore@intel.com>

So what the patch does is to replace two functions, acpi_set_firmware_waking_vector()
taking one u32 argument and acpi_set_firmware_waking_vector64() taking one u64
argument, with a modified acpi_set_firmware_waking_vector() taking two arguments
of type acpi_physical_address.  And it breaks compliation when applied to Linux
as is AFAICS, doesn't it?

I guess the point is to allow the OS to set firmware_waking_vector *and* clear
xfirmware_waking_vector at the same time (by passing 0 as the second argument
of the function).  And that helps to address the issue when xfirmware_waking_vector
has a random value to start with, we don't clear it and the BIOS thinks it is OK
to use it, right?

If that's the case, this patch should be combined with [4/32] and the signal-to-noise
ratio of [4/32] needs to be increased quite a bit.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1171007 — RE: [PATCH 03/32] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS.

SGksIFJhZmFlbA0KDQo+IEZyb206IFJhZmFlbCBKLiBXeXNvY2tpIFttYWlsdG86cmp3QHJqd3lz
b2NraS5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyNCwgMjAxNSA4OjMwIEFNDQo+IA0K
PiBPbiBGcmlkYXksIEp1bmUgMTksIDIwMTUgMTE6Mzg6MjggQU0gTHYgWmhlbmcgd3JvdGU6DQo+
ID4gQUNQSUNBIGNvbW1pdCA3YWE1OThkNzExNjQ0YWIwZGU1ZjcwYWQ4OGYxZTJkZTI1MzExNWU0
DQo+ID4NCj4gPiBUaGUgcm9vdCBjYXVzZSBvZiB0aGUgcmVwb3J0ZWQgYnVnIG1pZ2h0IGJlIG9u
ZSBvZiB0aGUgZm9sbG93aW5nczoNCj4gPiAxLiBCSU9TIG1heSBmYXZvciB0aGUgNjQtYml0IGZp
cm13YXJlIHdha2luZyB2ZWN0b3IgYWRkcmVzcyB3aGVuIHRoZQ0KPiA+ICAgIHZlcnNpb24gb2Yg
dGhlIEZBQ1MgaXMgZ3JlYXRlciB0aGFuIDAgYW5kIExpbnV4IGN1cnJlbnRseSBvbmx5IHN1cHBv
cnRzDQo+ID4gICAgcmVzdW1pbmcgZnJvbSB0aGUgcmVhbCBtb2RlLCBzbyB0aGUgNjQtYml0IGZp
cm13YXJlIHdha2luZyB2ZWN0b3IgaGFzDQo+ID4gICAgbmV2ZXIgYmVlbiBzZXQgYW5kIG1pZ2h0
IGJlIGludmFsaWQgdG8gQklPUyB3aGlsZSB0aGUgY29tbWl0IGVuYWJsZXMNCj4gPiAgICBoaWdo
ZXIgdmVyc2lvbiBGQUNTLg0KPiA+IDIuIEJJT1MgbWF5IGZhdm9yIHRoZSBGQUNTIHJlcG9ydGVk
IHZpYSB0aGUgIkZJUk1XQVJFX0NUUkwiIGZpZWxkIGluIHRoZQ0KPiA+ICAgIEZBRFQgd2hpbGUg
dGhlIGNvbW1pdCBkb2Vzbid0IHNldCB0aGUgZmlybXdhcmUgd2FraW5nIHZlY3RvciBhZGRyZXNz
IG9mDQo+ID4gICAgdGhlIEZBQ1MgcmVwb3J0ZWQgYnkgIkZJUk1XQVJFX0NUUkwiLCBpdCBvbmx5
IHNldHMgdGhlIGZpcndhcmUgd2FraW5nDQo+ID4gICAgdmVjdG9yIGFkZHJlc3Mgb2YgdGhlIEZB
Q1MgcmVwb3J0ZWQgYnkgIlhfRklSTVdBUkVfQ1RSTCIuDQo+ID4NCj4gPiBUaGlzIHBhdGNoIGV4
Y2x1ZGVzIHRoZSBjYXNlcyB0aGF0IGNhbiB0cmlnZ2VyIHRoZSBidWdzIGNhdXNlZCBieSB0aGUg
cm9vdA0KPiA+IGNhdXNlIDEuDQo+ID4NCj4gPiBBQ1BJIHNwZWNpZmljYXRpb24gc2F5czoNCj4g
PiBBLiAzMi1iaXQgRkFDUyBhZGRyZXNzIChGSVJNV0FSRV9DVFJMIGZpZWxkIGluIEZBRFQpOg0K
PiA+ICAgIFBoeXNpY2FsIG1lbW9yeSBhZGRyZXNzIG9mIHRoZSBGQUNTLCB3aGVyZSBPU1BNIGFu
ZCBmaXJtd2FyZSBleGNoYW5nZQ0KPiA+ICAgIGNvbnRyb2wgaW5mb3JtYXRpb24uDQo+ID4gICAg
SWYgdGhlIFhfRklSTVdBUkVfQ1RSTCBmaWVsZCBjb250YWlucyBhIG5vbiB6ZXJvIHZhbHVlIHRo
ZW4gdGhpcyBmaWVsZA0KPiA+ICAgIG11c3QgYmUgemVyby4NCj4gPiAgICBBIHplcm8gdmFsdWUg
aW5kaWNhdGVzIHRoYXQgbm8gRkFDUyBpcyBzcGVjaWZpZWQgYnkgdGhpcyBmaWVsZC4NCj4gPiBC
LiA2NC1iaXQgRkFDUyBhZGRyZXNzIChYX0ZJUk1XQVJFX0NUUkwgZmllbGQgaW4gRkFEVCk6DQo+
ID4gICAgNjRiaXQgcGh5c2ljYWwgbWVtb3J5IGFkZHJlc3Mgb2YgdGhlIEZBQ1MuDQo+ID4gICAg
VGhpcyBmaWVsZCBpcyB1c2VkIHdoZW4gdGhlIHBoeXNpY2FsIGFkZHJlc3Mgb2YgdGhlIEZBQ1Mg
aXMgYWJvdmUgNEdCLg0KPiA+ICAgIElmIHRoZSBGSVJNV0FSRV9DVFJMIGZpZWxkIGNvbnRhaW5z
IGEgbm9uIHplcm8gdmFsdWUgdGhlbiB0aGlzIGZpZWxkDQo+ID4gICAgbXVzdCBiZSB6ZXJvLg0K
PiA+ICAgIEEgemVybyB2YWx1ZSBpbmRpY2F0ZXMgdGhhdCBubyBGQUNTIGlzIHNwZWNpZmllZCBi
eSB0aGlzIGZpZWxkLg0KPiA+IFRodXMgdGhlIDMyYml0IGFuZCA2NGJpdCBmaXJtd2FyZSB3YWtp
bmcgdmVjdG9yIHNob3VsZCBpbmRpY2F0ZSBjb21wbGV0ZWx5DQo+ID4gZGlmZmVyZW50IHJlc3Vt
aW5nIGVudmlyb25tZW50IC0gcmVhbCBtb2RlICgxTUIgYWRkcmVzc2FibGUpIGFuZCBub24gcmVh
bA0KPiA+IG1vZGUgKDRHQisgYWRkcmVzc2FibGUpIGFuZCBjdXJyZW50bHkgTGludXggb25seSBz
dXBwb3J0cyByZXN1bWluZyBmcm9tDQo+ID4gcmVhbCBtb2RlLg0KPiA+DQo+ID4gVGhpcyBwYXRj
aCBlbmFibGVzIDY0LWJpdCBmaXJtd2FyZSB3YWtpbmcgdmVjdG9yIGZvciBzZWxlY3RlZCBGQUNT
IHZpYQ0KPiA+IGFjcGlfc2V0X2Zpcm13YXJlX3dha2luZ192ZWN0b3IoKSBzbyB0aGF0IGl0J3Mg
dXAgdG8gT1NQTXMgdG8gZGV0ZXJtaW5lIHdoaWNoDQo+ID4gcmVzdW1pbmcgbW9kZSBzaG91bGQg
YmUgdXNlZCBieSBCSU9TIGFuZCBBQ1BJQ0EgY2hhbmdlcyB3b24ndCB0cmlnZ2VyIHRoZQ0KPiA+
IGJ1Z3MgY2F1c2VkIGJ5IHRoZSByb290IGNhdXNlIDEuIEZvciBleGFtcGxlLCBMaW51eCBjYW4g
cGFzcw0KPiA+IHBoeXNpY2FsX2FkZHJlc3M2ND0wIGFzIHRoZSBwYXJhbWV0ZXIgb2YgYWNwaV9z
ZXRfZmlybXdhcmVfd2FraW5nX3ZlY3RvcigpIHRvDQo+ID4gaW5kaWNhdGUgbm8gNjRiaXQgd2Fr
aW5nIHZlY3RvciBzdXBwb3J0LiBMdiBaaGVuZy4NCj4gPg0KPiA+IExpbms6IGh0dHBzOi8vYnVn
emlsbGEua2VybmVsLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NzQwMjENCj4gPiBMaW5rOiBodHRwczov
L2dpdGh1Yi5jb20vYWNwaWNhL2FjcGljYS9jb21taXQvN2FhNTk4ZDcNCj4gPiBSZXBvcnRlZC1h
bmQtdGVzdGVkLWJ5OiBPc3dhbGQgQnVkZGVuaGFnZW4gPG9zc2lAa2RlLm9yZz4NCj4gPiBTaWdu
ZWQtb2ZmLWJ5OiBMdiBaaGVuZyA8bHYuemhlbmdAaW50ZWwuY29tPg0KPiA+IFNpZ25lZC1vZmYt
Ynk6IEJvYiBNb29yZSA8cm9iZXJ0Lm1vb3JlQGludGVsLmNvbT4NCj4gDQo+IFNvIHdoYXQgdGhl
IHBhdGNoIGRvZXMgaXMgdG8gcmVwbGFjZSB0d28gZnVuY3Rpb25zLCBhY3BpX3NldF9maXJtd2Fy
ZV93YWtpbmdfdmVjdG9yKCkNCj4gdGFraW5nIG9uZSB1MzIgYXJndW1lbnQgYW5kIGFjcGlfc2V0
X2Zpcm13YXJlX3dha2luZ192ZWN0b3I2NCgpIHRha2luZyBvbmUgdTY0DQo+IGFyZ3VtZW50LCB3
aXRoIGEgbW9kaWZpZWQgYWNwaV9zZXRfZmlybXdhcmVfd2FraW5nX3ZlY3RvcigpIHRha2luZyB0
d28gYXJndW1lbnRzDQo+IG9mIHR5cGUgYWNwaV9waHlzaWNhbF9hZGRyZXNzLiAgQW5kIGl0IGJy
ZWFrcyBjb21wbGlhdGlvbiB3aGVuIGFwcGxpZWQgdG8gTGludXgNCj4gYXMgaXMgQUZBSUNTLCBk
b2Vzbid0IGl0Pw0KDQpZZXMsIGFuZCB0aGUgZml4IGlzIHBhdGNoIDA0LzMyLg0KDQo+IEkgZ3Vl
c3MgdGhlIHBvaW50IGlzIHRvIGFsbG93IHRoZSBPUyB0byBzZXQgZmlybXdhcmVfd2FraW5nX3Zl
Y3RvciAqYW5kKiBjbGVhcg0KPiB4ZmlybXdhcmVfd2FraW5nX3ZlY3RvciBhdCB0aGUgc2FtZSB0
aW1lIChieSBwYXNzaW5nIDAgYXMgdGhlIHNlY29uZCBhcmd1bWVudA0KPiBvZiB0aGUgZnVuY3Rp
b24pLiAgQW5kIHRoYXQgaGVscHMgdG8gYWRkcmVzcyB0aGUgaXNzdWUgd2hlbiB4ZmlybXdhcmVf
d2FraW5nX3ZlY3Rvcg0KPiBoYXMgYSByYW5kb20gdmFsdWUgdG8gc3RhcnQgd2l0aCwgd2UgZG9u
J3QgY2xlYXIgaXQgYW5kIHRoZSBCSU9TIHRoaW5rcyBpdCBpcyBPSw0KPiB0byB1c2UgaXQsIHJp
Z2h0Pw0KDQpZZXMuDQoNCj4gSWYgdGhhdCdzIHRoZSBjYXNlLCB0aGlzIHBhdGNoIHNob3VsZCBi
ZSBjb21iaW5lZCB3aXRoIFs0LzMyXSBhbmQgdGhlIHNpZ25hbC10by1ub2lzZQ0KPiByYXRpbyBv
ZiBbNC8zMl0gbmVlZHMgdG8gYmUgaW5jcmVhc2VkIHF1aXRlIGEgYml0Lg0KDQpJJ2xsIGNvbWJp
bmUgdGhlIDIgcGF0Y2hlcy4NCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMNCi1Mdg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web