All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Nadav Amit <namit@cs.technion.ac.il>, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Save bits by merging Mmx/Sse/Avx bits
Date: Thu, 06 Nov 2014 22:51:16 +0100	[thread overview]
Message-ID: <545BED54.4080305@redhat.com> (raw)
In-Reply-To: <D83D293D-951F-4528-A4D2-2E912B181606@gmail.com>



On 06/11/2014 19:52, Nadav Amit wrote:
> 
>> On Nov 6, 2014, at 16:10, Paolo Bonzini <pbonzini@redhat.com> 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

  reply	other threads:[~2014-11-06 21:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06  9:15 [PATCH] KVM: x86: Save bits by merging Mmx/Sse/Avx bits Nadav Amit
2014-11-06 14:10 ` Paolo Bonzini
2014-11-06 18:52   ` Nadav Amit
2014-11-06 21:51     ` Paolo Bonzini [this message]
2014-11-07 17:37 ` Radim Krčmář
2014-11-07 17:39   ` Paolo Bonzini
2014-11-07 17:49     ` Radim Krčmář

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=545BED54.4080305@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=nadav.amit@gmail.com \
    --cc=namit@cs.technion.ac.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.