Avi Kivity wrote:
On 09/03/2010 12:27 PM, Andre Przywara wrote:
The AMD extension to AVX (FMA4, XOP) work on the same YMM register set
as AVX, so they are safe for guests to use, as long as AVX itself
is allowed.
Signed-off-by: Andre Przywara<andre.przywara@xxxxxxx>
---
arch/x86/kvm/x86.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3a09c62..eb89e7b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1996,8 +1996,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
const u32 kvm_supported_word6_x86_features =
F(LAHF_LM) | F(CMP_LEGACY) | F(SVM) | 0 /* ExtApicSpace */ |
F(CR8_LEGACY) | F(ABM) | F(SSE4A) | F(MISALIGNSSE) |
- F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(SSE5) |
- 0 /* SKINIT */ | 0 /* WDT */;
+ F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(XOP) |
+ 0 /* SKINIT, WDT, LWP */ | F(FMA4) | F(TBM);
Should be folded into patch 1 to avoid build breakage.
Right you are. Thanks for spotting this. I fixed that and will sent out
a version 2 later.
Did we really enable "sse5" before xsave? That looks broken, but I
guess no real harm if xsave itself is not enabled.
Yes. It somehow slipped through when you introduced the other feature
flags to KVM. I also think this is not a serious problem.
BTW: I realized that AES is currently denied. Reading the manual I see
that it operates on SSE registers, so it should be safe to be passed
through. The only drawback is that it would change the visible CPUID on
CPUs that already have AES, whereas earlier KVM versions did hide it.
This could become a problem with migration. But if you agree, I'd
integrate this flag in the v2 series.
Regards,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
