diff options
| author | Jan Beulich <jbeulich@suse.com> | 2011-12-16 15:45:40 +0100 |
|---|---|---|
| committer | Jan Beulich <jbeulich@suse.com> | 2011-12-16 15:45:40 +0100 |
| commit | a1b22e625dee30b9ca572e5b7fe66f1aebd44d7d (patch) | |
| tree | 3284bfa225b3b7e5716d3aede98720684e1f46f0 /xen/include/asm-x86/amd.h | |
| parent | 6e359548a1c9afdaee765ccd8b9635424acdb1bd (diff) | |
| download | xen-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/include/asm-x86/amd.h')
| -rw-r--r-- | xen/include/asm-x86/amd.h | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/xen/include/asm-x86/amd.h b/xen/include/asm-x86/amd.h index d7fb1a5b53..2ff818872f 100644 --- a/xen/include/asm-x86/amd.h +++ b/xen/include/asm-x86/amd.h @@ -134,6 +134,12 @@ AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf), \ AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0x1, 0x0)) +#define AMD_ERRATUM_573 \ + AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x0f, 0x0, 0x0, 0xff, 0xf), \ + AMD_MODEL_RANGE(0x10, 0x0, 0x0, 0xff, 0xf), \ + AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf), \ + AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf)) + struct cpuinfo_x86; int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...); |