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>
--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -9,5 +9,7 @@ typedef bool bool_t;
#define BUG() abort()
+#define cpu_has_amd_erratum(nr) 0
+
#include "x86_emulate/x86_emulate.h"
#include "x86_emulate/x86_emulate.c"
--- 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(¤t_cpu_data, AMD_ERRATUM_##nr)
#include "x86_emulate/x86_emulate.c"
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2761,6 +2761,9 @@ x86_emulate(
case 0xd9: /* FPU 0xd9 */
switch ( modrm )
{
+ case 0xfb: /* fsincos */
+ fail_if(cpu_has_amd_erratum(573));
+ /* fall through */
case 0xc0 ... 0xc7: /* fld %stN */
case 0xc8 ... 0xcf: /* fxch %stN */
case 0xd0: /* fnop */
@@ -2786,7 +2789,6 @@ x86_emulate(
case 0xf8: /* fprem */
case 0xf9: /* fyl2xp1 */
case 0xfa: /* fsqrt */
- case 0xfb: /* fsincos */
case 0xfc: /* frndint */
case 0xfd: /* fscale */
case 0xfe: /* fsin */
--- 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, ...);
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2011-Dec-15 16:53 UTC
Re: [PATCH] x86/emulator: workaround for AMD erratum 573
On 15/12/2011 13:16, "Jan Beulich" <JBeulich@suse.com> wrote:> 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>> --- a/tools/tests/x86_emulator/x86_emulate.c > +++ b/tools/tests/x86_emulator/x86_emulate.c > @@ -9,5 +9,7 @@ typedef bool bool_t; > > #define BUG() abort() > > +#define cpu_has_amd_erratum(nr) 0 > + > #include "x86_emulate/x86_emulate.h" > #include "x86_emulate/x86_emulate.c" > --- 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(¤t_cpu_data, AMD_ERRATUM_##nr) > > #include "x86_emulate/x86_emulate.c" > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -2761,6 +2761,9 @@ x86_emulate( > case 0xd9: /* FPU 0xd9 */ > switch ( modrm ) > { > + case 0xfb: /* fsincos */ > + fail_if(cpu_has_amd_erratum(573)); > + /* fall through */ > case 0xc0 ... 0xc7: /* fld %stN */ > case 0xc8 ... 0xcf: /* fxch %stN */ > case 0xd0: /* fnop */ > @@ -2786,7 +2789,6 @@ x86_emulate( > case 0xf8: /* fprem */ > case 0xf9: /* fyl2xp1 */ > case 0xfa: /* fsqrt */ > - case 0xfb: /* fsincos */ > case 0xfc: /* frndint */ > case 0xfd: /* fscale */ > case 0xfe: /* fsin */ > --- 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, ...); > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel
Boris Ostrovsky
2011-Dec-15 17:52 UTC
Re: [PATCH] x86/emulator: workaround for AMD erratum 573
>--- 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))Families 0xf and 0x11 are not affected by erratum 573. -boris
Jan Beulich
2011-Dec-16 08:26 UTC
Re: [PATCH] x86/emulator: workaround for AMD erratum 573
>>> On 15.12.11 at 18:52, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote: >> --- 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)) > > Families 0xf and 0x11 are not affected by erratum 573.Are you saying that these two documents 33610 Rev. 3.48 December 2011 41788 Rev. 3.10 December 2011 both wrong? For fam 0xf it may be that we can set a lower bound for pre-NPT ones if those indeed are unaffected (but we''d like to be sure this is the case) - that would appear to be all with a model below 0x40. Please clarify. Jan
Boris Ostrovsky
2011-Dec-16 14:15 UTC
Re: [PATCH] x86/emulator: workaround for AMD erratum 573
On 12/16/11 03:26, Jan Beulich wrote:>>>> On 15.12.11 at 18:52, Boris Ostrovsky<boris.ostrovsky@amd.com> wrote: >>> --- 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)) >> >> Families 0xf and 0x11 are not affected by erratum 573. > > Are you saying that these two documents > > 33610 Rev. 3.48 December 2011 > 41788 Rev. 3.10 December 2011 > > both wrong? For fam 0xf it may be that we can set a lower bound for > pre-NPT ones if those indeed are unaffected (but we''d like to be sure > this is the case) - that would appear to be all with a model below 0x40. > > Please clarify.Sorry, my bad. You are right --- somehow I thought it was only 10h and 12h. -boris