Jan Beulich
2013-Sep-13 08:07 UTC
[PATCH] 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);
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Keir Fraser
2013-Sep-13 10:14 UTC
Re: [PATCH] x86: machine_restart() must not call acpi_dmar_reinstate() twice
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