>>> On 21.12.11 at 12:22, "Wei, Gang" wrote:
> Without this delay, Xen could not bring APs up while working with TXT/tboot,
> because tboot need some time in APs to handle INIT before becoming ready for
> receiving SIPIs. (this delay was removed as part of c/s 23724 by Tim Deegan)
>
> Signed-of
>>> On 23.12.11 at 04:14, "Wei, Gang" wrote:
> Without this delay, Xen could not bring APs up while working with TXT/tboot,
> because tboot need some time in APs to handle INIT before becoming ready for
> receiving SIPIs.(this delay was removed as part of c/s 23724 by Tim Deegan)
>
> Signed-off
>>> "Wei, Gang" 12/27/11 11:07 AM >>>
>Second way, I tested it. The minimum value I tested is udelay(1). So I think
>udelay(10) should give enough margin.
Ah, that's what I was after. Worth stating in the code comment perhaps.
Jan
--
>>> On 05.01.12 at 15:53, "Wei, Gang" wrote:
> tboot may be trying to put APs waiting in MWAIT loops before launching Xen.
> Xen could check the new flag field in v6 tboot shared page for the hint. If
> TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write the
> monitored memo
>>> On 09.01.12 at 17:01, "Wei, Gang" wrote:
> tboot may be trying to put APs waiting in MWAIT loops before launching Xen.
> Xen could check the new flag field in v6 tboot shared page for the hint. If
> TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write the
> monitored memo
istinguish "extended" from "legacy" sleep.
This requires adjusting TXT, but the adjustments only go as far as
failing the extended mode call (since, looking at the TXT interface,
there doesn't even appear to be precautions to deal with that
alternative interface).
Signed
>>> On 11.03.13 at 14:21, Konrad Rzeszutek Wilk wrote:
> Could the commit should also mention what version of the Xen hypervisor
> supports this new flag and takes action on it?
Do you really think this is needed? I generally try to stay away
from doing such, since backports can easily invalidate
>>> On 11.03.13 at 14:53, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 11, 2013 at 01:32:17PM +, Jan Beulich wrote:
>> >>> On 11.03.13 at 14:21, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > Could the commit should also mention what version of
ypervisor change underlying this is commit 62d1a69 ("ACPI: support
v5 (reduced HW) sleep interface") on the master branch of
git://xenbits.xen.org/xen.git.
Signed-off-by: Jan Beulich
Cc: Richard L Maliszewski
Cc: Gang Wei
Cc: Shane Wang
---
v2: Extend description to include reference to
>>> On 12.03.13 at 07:39, "Wei, Gang" wrote:
> Jan Beulich wrote on 2013-03-11:
>> In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
>> reduced hardware sleep support, and the two changes didn't get
>> synchronized: The n
>>> On 12.03.13 at 01:59, "Zheng, Lv" wrote:
>> > +#include
>
> This line shouldn't appear in ACPICA codes (drivers/acpi/acpica).
> Please try to declare OSL interfaces via include/acpi/platform/aclinux.h.
I'm sorry, but why am I not permitted to follow code that's
already there:
- hwsleep.c al
>>> On 11.03.13 at 15:51, "Rafael J. Wysocki" wrote:
> On Monday, March 11, 2013 02:06:51 PM Jan Beulich wrote:
>> In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
>> reduced hardware sleep support, and the two changes didn't get
>
>>> On 26.06.13 at 16:06, Ben Guthro wrote:
> --- a/arch/x86/kernel/tboot.c
> +++ b/arch/x86/kernel/tboot.c
> @@ -273,7 +273,8 @@ static void tboot_copy_fadt(const struct acpi_table_fadt
> *fadt)
> offsetof(struct acpi_table_facs, firmware_waking_vector);
> }
>
> -static int tboo
>>> On 26.06.13 at 16:55, Ben Guthro wrote:
> On Wed, Jun 26, 2013 at 10:44 AM, Jan Beulich wrote:
>>>>> On 26.06.13 at 16:06, Ben Guthro wrote:
>>> --- a/arch/x86/kernel/tboot.c
>>> +++ b/arch/x86/kernel/tboot.c
>>> @@ -27
14 matches
Mail list logo
