From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: [PATCH] x86emul: tighten CLFLUSH emulation
Date: Mon, 12 Jan 2015 08:23:09 +0000
Message-ID: <54B3927D020000780005374A@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part76439C7D.1__="
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1YAaHK-0004LF-J5
	for xen-devel@lists.xenproject.org; Mon, 12 Jan 2015 08:23:14 +0000
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: xen-devel <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part76439C7D.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While for us it's not as bad as it was for Linux, their commit
13e457e0ee ("KVM: x86: Emulator does not decode clflush well", by
Nadav Amit <namit@cs.technion.ac.il>) nevertheless points out two
shortcomings in our code: opcode 0F AE /7 is clflush only when it uses
a memory mode (otherwise it's SFENCE) and when there's no REP prefix
(an operand size prefix is fine, as that's CLFLUSHOPT).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4400,7 +4400,9 @@ x86_emulate(
     case 0xae: /* Grp15 */
         switch ( modrm_reg & 7 )
         {
-        case 7: /* clflush */
+        case 7: /* clflush{,opt} */
+            fail_if(modrm_mod =3D=3D 3);
+            fail_if(rep_prefix());
             fail_if(ops->wbinvd =3D=3D NULL);
             if ( (rc =3D ops->wbinvd(ctxt)) !=3D 0 )
                 goto done;




--=__Part76439C7D.1__=
Content-Type: text/plain; name="x86emul-clflush.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86emul-clflush.patch"

x86emul: tighten CLFLUSH emulation=0A=0AWhile for us it's not as bad as it =
was for Linux, their commit=0A13e457e0ee ("KVM: x86: Emulator does not =
decode clflush well", by=0ANadav Amit <namit@cs.technion.ac.il>) neverthele=
ss points out two=0Ashortcomings in our code: opcode 0F AE /7 is clflush =
only when it uses=0Aa memory mode (otherwise it's SFENCE) and when there's =
no REP prefix=0A(an operand size prefix is fine, as that's CLFLUSHOPT).=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/x=
86_emulate/x86_emulate.c=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.c=0A@=
@ -4400,7 +4400,9 @@ x86_emulate(=0A     case 0xae: /* Grp15 */=0A         =
switch ( modrm_reg & 7 )=0A         {=0A-        case 7: /* clflush */=0A+ =
       case 7: /* clflush{,opt} */=0A+            fail_if(modrm_mod =3D=3D =
3);=0A+            fail_if(rep_prefix());=0A             fail_if(ops->wbinv=
d =3D=3D NULL);=0A             if ( (rc =3D ops->wbinvd(ctxt)) !=3D 0 )=0A =
                goto done;=0A
--=__Part76439C7D.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=__Part76439C7D.1__=--