On 06/11/2014 19:52, Nadav Amit wrote: > >> On Nov 6, 2014, at 16:10, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >> >> >> >> On 06/11/2014 10:15, Nadav Amit wrote: >>> As we run out of bits in the KVM emulator instruction flags, we can merge >>> together the Mmx/Sse/Avx bits. These bits are mutual exclusive (i.e., each >>> instruction is either MMX, SSE, AVX, or none), so we can save one bit in the >>> flags by merging them. >> >> Do we need the Avx bit at all? Currently it is a dup of Unaligned, and >> I think we can just reuse Unaligned. If we see VEX, we just do "ctxt->d >> |= Unaligned". >> >> AVX instructions are just tweaks of the operand length and the alignment >> restrictions of SSE instructions, there is nothing really special about >> them. > > Hmm… I do not think this is the case. > AVX instruction have some things in common, which are currently not > implemented (since no instruction is marked as AVX), but should be if > anyone implements the emulation of AVX instructions: > > 1. They should cause #UD if CR4.OSXSAVE=0 or XCR0[2:1] != 3, or CPUID[1].AVX = 0. > 2. They should cause #NM if CR0.TS = 1 (like SSE/MMX) > 3. They work on YMM registers (256-bit long; unlike SSE/MMX) 4. They always accept unaligned arguments, with some exceptions. But encoding-wise, (1) and (3) are determined by the VEX prefix I think. Regarding (3), there are also 128-bit AVX instruction, e.g. vmovpd xmm0, xmm1. I'm not sure if those also cause #UD for case (1). And as you said, (2) is common to SSE and AVX. For what I understood, AVX instructions are basically SSE instructions as far as decoding is concerned, only there is always a VEX prefix and there is never a 66/F2/F3 prefix. Paolo -- 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
