All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 00/10] x86emul: full coverage mem access / write testing
Date: Tue, 4 Aug 2020 09:38:40 +0200	[thread overview]
Message-ID: <f86770d9-74fc-b125-5f48-ce36ec6b5ac9@suse.com> (raw)
In-Reply-To: <60a128e9-0480-a753-4aa8-177c270d09f4@citrix.com>

On 03.08.2020 18:40, Andrew Cooper wrote:
> On 03/08/2020 15:47, Jan Beulich wrote:
>> ... 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.
> 
> Seems fine to me.
> 
> I have encountered a failure on AMD Naples which I doubt is related to
> this series, but is blocking testing on some of the content here.
> 
> Testing fnstenv 4(%ecx)...              failed!
> 
> AMD Fam17 does have the fcs/fds save-as-zero logic which is still not
> wired up anywhere in Xen, which seems like the most likely candidate
> here (without having investigated the issue at all yet).

FIP/FOP/FDP are lost over a context switch in Linux here, as it
seems. No idea yet why a context switch would happen this
reliably on Fam17, but not on Fam15 (where I'd expect the behavior
to be the same as long as there's no unmasked exception).

Jan


  parent reply	other threads:[~2020-08-04  7:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 14:47 [PATCH 00/10] x86emul: full coverage mem access / write testing Jan Beulich
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 [this message]
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=f86770d9-74fc-b125-5f48-ce36ec6b5ac9@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.