All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH 00/10] x86emul: full coverage mem access / write testing
Date: Mon, 3 Aug 2020 16:47:39 +0200	[thread overview]
Message-ID: <97ca3d9c-7540-c7b1-cf84-34c75c9127df@suse.com> (raw)

... and a few fixes resulting from this work. This completes what
was started for legacy encoded GPR insns in a rush before 4.14.

There's one thing I'm still planning on top of both this and the
EVEX-disp8 checking: For all encodings we produce via general
logic (and in particular without involvement of any assembler) I'd
like to add a kind of logging mechanism, the output of which could
be fed to gas and then some disassembler, to allow verification
that the produced encodings are actually valid ones. See e.g. the
first patch here or commit 5f55389d6960 - the problems addressed
there could have been caught earlier if the generated encodings
could be easily disassembled. What's not clear to me here is
whether this is deemed generally useful, or whether I should make
this a private addition of mine.

01: adjustments to mem access / write logic testing
02: extend decoding / mem access testing to FPU insns
03: extend decoding / mem access testing to MMX / SSE insns
04: extend decoding / mem access testing to VEX-encoded insns
05: extend decoding / mem access testing to XOP-encoded insns
06: AVX512{F,BW} down conversion moves are memory writes
07: AVX512F scatter insns are memory writes
08: AVX512PF insns aren't memory accesses
09: extend decoding / mem access testing to EVEX-encoded insns
10: correct AVX512_BF16 insn names in EVEX Disp8 test

Jan


             reply	other threads:[~2020-08-03 14:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 14:47 Jan Beulich [this message]
2020-08-03 14:50 ` [PATCH 01/10] x86emul: adjustments to mem access / write logic testing Jan Beulich
2020-08-03 14:50 ` [PATCH 02/10] x86emul: extend decoding / mem access testing to FPU insns Jan Beulich
2020-08-03 14:50 ` [PATCH 03/10] x86emul: extend decoding / mem access testing to MMX / SSE insns Jan Beulich
2020-08-03 16:42   ` Andrew Cooper
2020-08-04  6:40     ` Jan Beulich
2020-08-03 14:51 ` [PATCH 04/10] x86emul: extend decoding / mem access testing to VEX-encoded insns Jan Beulich
2020-08-03 14:51 ` [PATCH 05/10] x86emul: extend decoding / mem access testing to XOP-encoded insns Jan Beulich
2020-08-03 14:52 ` [PATCH 06/10] x86emul: AVX512{F, BW} down conversion moves are memory writes Jan Beulich
2020-08-03 14:53 ` [PATCH 07/10] x86emul: AVX512F scatter insns " Jan Beulich
2020-08-03 14:53 ` [PATCH 08/10] x86emul: AVX512PF insns aren't memory accesses Jan Beulich
2020-08-03 14:54 ` [PATCH 09/10] x86emul: extend decoding / mem access testing to EVEX-encoded insns Jan Beulich
2020-08-03 14:54 ` [PATCH 10/10] x86emul: correct AVX512_BF16 insn names in EVEX Disp8 test Jan Beulich
2020-08-03 16:40 ` [PATCH 00/10] x86emul: full coverage mem access / write testing Andrew Cooper
2020-08-04  6:42   ` Jan Beulich
2020-08-04  7:38   ` Jan Beulich
2020-08-04 14:59 ` Andrew Cooper

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=97ca3d9c-7540-c7b1-cf84-34c75c9127df@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.