* [PATCH] x86: machine_restart() must not call acpi_dmar_reinstate() twice
@ 2013-09-13 8:07 Jan Beulich
2013-09-13 10:14 ` Keir Fraser
0 siblings, 1 reply; 2+ messages in thread
From: Jan Beulich @ 2013-09-13 8:07 UTC (permalink / raw)
To: xen-devel; +Cc: Keir Fraser
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
.. as that function is not idempotent (it always alters the table
checksum). The (generally) duplicate call was a result from it being
made before machine_restart() re-invoking itself on the boot CPU.
Considering that no problem arose so far from the table corruption I
doubt that we need to restore the correct table signature on the
reboot path in general. The only case I can see this as potentially
necessary is the tboot one, hence do the call just in that case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that this was found to be particularly an issue backporting
2ee9cbf9 ("ACPI: fix acpi_os_map_memory()") to 4.1.x: The first
invocation would acquire the lock in acpi_os_map_memory(), and since
the lock never gets released, the second invocation gets stuck.
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -470,8 +470,6 @@ void machine_restart(unsigned int delay_
console_start_sync();
spin_debug_disable();
- acpi_dmar_reinstate();
-
local_irq_enable();
/* Ensure we are the boot CPU. */
@@ -496,7 +494,10 @@ void machine_restart(unsigned int delay_
mdelay(delay_millisecs);
if ( tboot_in_measured_env() )
+ {
+ acpi_dmar_reinstate();
tboot_shutdown(TB_SHUTDOWN_REBOOT);
+ }
efi_reset_system(reboot_mode != 0);
[-- Attachment #2: x86-restart-DMAR-reinstate.patch --]
[-- Type: text/plain, Size: 1429 bytes --]
x86: machine_restart() must not call acpi_dmar_reinstate() twice
.. as that function is not idempotent (it always alters the table
checksum). The (generally) duplicate call was a result from it being
made before machine_restart() re-invoking itself on the boot CPU.
Considering that no problem arose so far from the table corruption I
doubt that we need to restore the correct table signature on the
reboot path in general. The only case I can see this as potentially
necessary is the tboot one, hence do the call just in that case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that this was found to be particularly an issue backporting
2ee9cbf9 ("ACPI: fix acpi_os_map_memory()") to 4.1.x: The first
invocation would acquire the lock in acpi_os_map_memory(), and since
the lock never gets released, the second invocation gets stuck.
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -470,8 +470,6 @@ void machine_restart(unsigned int delay_
console_start_sync();
spin_debug_disable();
- acpi_dmar_reinstate();
-
local_irq_enable();
/* Ensure we are the boot CPU. */
@@ -496,7 +494,10 @@ void machine_restart(unsigned int delay_
mdelay(delay_millisecs);
if ( tboot_in_measured_env() )
+ {
+ acpi_dmar_reinstate();
tboot_shutdown(TB_SHUTDOWN_REBOOT);
+ }
efi_reset_system(reboot_mode != 0);
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] x86: machine_restart() must not call acpi_dmar_reinstate() twice
2013-09-13 8:07 [PATCH] x86: machine_restart() must not call acpi_dmar_reinstate() twice Jan Beulich
@ 2013-09-13 10:14 ` Keir Fraser
0 siblings, 0 replies; 2+ messages in thread
From: Keir Fraser @ 2013-09-13 10:14 UTC (permalink / raw)
To: Jan Beulich, xen-devel
On 13/09/2013 01:07, "Jan Beulich" <JBeulich@suse.com> wrote:
> .. as that function is not idempotent (it always alters the table
> checksum). The (generally) duplicate call was a result from it being
> made before machine_restart() re-invoking itself on the boot CPU.
>
> Considering that no problem arose so far from the table corruption I
> doubt that we need to restore the correct table signature on the
> reboot path in general. The only case I can see this as potentially
> necessary is the tboot one, hence do the call just in that case.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
> ---
> Note that this was found to be particularly an issue backporting
> 2ee9cbf9 ("ACPI: fix acpi_os_map_memory()") to 4.1.x: The first
> invocation would acquire the lock in acpi_os_map_memory(), and since
> the lock never gets released, the second invocation gets stuck.
>
> --- a/xen/arch/x86/shutdown.c
> +++ b/xen/arch/x86/shutdown.c
> @@ -470,8 +470,6 @@ void machine_restart(unsigned int delay_
> console_start_sync();
> spin_debug_disable();
>
> - acpi_dmar_reinstate();
> -
> local_irq_enable();
>
> /* Ensure we are the boot CPU. */
> @@ -496,7 +494,10 @@ void machine_restart(unsigned int delay_
> mdelay(delay_millisecs);
>
> if ( tboot_in_measured_env() )
> + {
> + acpi_dmar_reinstate();
> tboot_shutdown(TB_SHUTDOWN_REBOOT);
> + }
>
> efi_reset_system(reboot_mode != 0);
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-09-13 10:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-13 8:07 [PATCH] x86: machine_restart() must not call acpi_dmar_reinstate() twice Jan Beulich
2013-09-13 10:14 ` Keir Fraser
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).