From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] KVM: x86: Save bits by merging Mmx/Sse/Avx bits Date: Thu, 06 Nov 2014 22:51:16 +0100 Message-ID: <545BED54.4080305@redhat.com> References: <1415265301-16746-1-git-send-email-namit@cs.technion.ac.il> <545B8149.2050808@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Nadav Amit , kvm@vger.kernel.org To: Nadav Amit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53213 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751088AbaKFVv2 (ORCPT ); Thu, 6 Nov 2014 16:51:28 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 06/11/2014 19:52, Nadav Amit wrote: >=20 >> On Nov 6, 2014, at 16:10, Paolo Bonzini 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= =2E, each >>> instruction is either MMX, SSE, AVX, or none), so we can save one b= it 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 "ctx= t->d >> |=3D Unaligned". >> >> AVX instructions are just tweaks of the operand length and the align= ment >> restrictions of SSE instructions, there is nothing really special ab= out >> them. >=20 > Hmm=85 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: >=20 > 1. They should cause #UD if CR4.OSXSAVE=3D0 or XCR0[2:1] !=3D 3, or C= PUID[1].AVX =3D 0. > 2. They should cause #NM if CR0.TS =3D 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= =2E 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. =46or what I understood, AVX instructions are basically SSE instruction= s as far as decoding is concerned, only there is always a VEX prefix and there is never a 66/F2/F3 prefix. Paolo