a4d1d9fe03
bnc#828623 - bnc#839596 - VUL-0: CVE-2013-1442: XSA-62: xen: Information leak on AVX and/or LWP capable CPUs 5242a1b5-x86-xsave-initialize-extended-register-state-when-guests-enable-it.patch - bnc#840592 - VUL-0: CVE-2013-4355: XSA-63: xen: Information leaks through I/O instruction emulation CVE-2013-4355-xsa63.patch - bnc#840593 - VUL-0: CVE-2013-4356: XSA-64: xen: Memory accessible by 64-bit PV guests under live migration CVE-2013-4356-xsa64.patch - bnc#841766 - VUL-1: CVE-2013-4361: XSA-66: xen: Information leak through fbld instruction emulation CVE-2013-4361-xsa66.patch - bnc#833796 - L3: Xen: migration broken from xsave-capable to xsave-incapable host 52205e27-x86-xsave-initialization-improvements.patch 522dc0e6-x86-xsave-fix-migration-from-xsave-capable-to-xsave-incapable-host.patch - bnc#839600 - [HP BCS SLES11 Bug]: In HP’s UEFI x86_64 platform and sles11sp3 with xen environment, xen hypervisor will panic on multiple blades nPar. 523172d5-x86-fix-memory-cut-off-when-using-PFN-compression.patch - bnc#833251 - [HP BCS SLES11 Bug]: In HP’s UEFI x86_64 platform and with xen environment, in booting stage ,xen hypervisor will panic. 522d896b-x86-EFI-properly-handle-run-time-memory-regions-outside-the-1-1-map.patch - bnc#834751 - [HP BCS SLES11 Bug]: In xen, “shutdown –y 0 –h” cannot power off system 522d896b-x86-EFI-properly-handle-run-time-memory-regions-outside-the-1-1-map.patch OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=274
41 lines
1.3 KiB
Diff
41 lines
1.3 KiB
Diff
# Commit a54dc5f4fe1eae6b1beb21326ef0338cd3969cd1
|
|
# Date 2013-09-13 14:27:34 +0200
|
|
# Author Jan Beulich <jbeulich@suse.com>
|
|
# Committer Jan Beulich <jbeulich@suse.com>
|
|
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>
|
|
Acked-by: Keir Fraser <keir@xen.org>
|
|
|
|
--- a/xen/arch/x86/shutdown.c
|
|
+++ b/xen/arch/x86/shutdown.c
|
|
@@ -115,8 +115,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. */
|
|
@@ -141,7 +139,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);
|
|
|