aboutsummaryrefslogtreecommitdiffstats
path: root/xen/arch/x86/x86_emulate.c
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2011-12-16 15:45:40 +0100
committerJan Beulich <jbeulich@suse.com>2011-12-16 15:45:40 +0100
commita1b22e625dee30b9ca572e5b7fe66f1aebd44d7d (patch)
tree3284bfa225b3b7e5716d3aede98720684e1f46f0 /xen/arch/x86/x86_emulate.c
parent6e359548a1c9afdaee765ccd8b9635424acdb1bd (diff)
downloadxen-a1b22e625dee30b9ca572e5b7fe66f1aebd44d7d.tar.gz
xen-a1b22e625dee30b9ca572e5b7fe66f1aebd44d7d.tar.bz2
xen-a1b22e625dee30b9ca572e5b7fe66f1aebd44d7d.zip
x86/emulator: workaround for AMD erratum 573
The only cases where we might end up emulating fsincos (as any other x87 operations without memory operands) are - when a HVM guest is in real mode (not applicable on AMD) - between two half page table updates in PAE mode (unlikely, and not doing the emulation here does affect only performance, not correctness) - when a guest maliciously (or erroneously) modifies an (MMIO or page table update) instruction under emulation (unspecified behavior) Hence, in order to avoid the erratum to cause harm to the entire host, don't emulate fsincos on the affected AMD CPU families. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
Diffstat (limited to 'xen/arch/x86/x86_emulate.c')
-rw-r--r--xen/arch/x86/x86_emulate.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/xen/arch/x86/x86_emulate.c b/xen/arch/x86/x86_emulate.c
index fbf740efee..91f524fc87 100644
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -10,8 +10,14 @@
*/
#include <asm/x86_emulate.h>
+#include <asm/processor.h> /* current_cpu_info */
+#include <asm/amd.h> /* cpu_has_amd_erratum() */
/* Avoid namespace pollution. */
#undef cmpxchg
+#undef cpuid
+
+#define cpu_has_amd_erratum(nr) \
+ cpu_has_amd_erratum(&current_cpu_data, AMD_ERRATUM_##nr)
#include "x86_emulate/x86_emulate.c"