mbox series

[00/10] x86emul: full coverage mem access / write testing

Message ID 97ca3d9c-7540-c7b1-cf84-34c75c9127df@suse.com (mailing list archive)
Headers show
Series x86emul: full coverage mem access / write testing | expand

Message

Jan Beulich Aug. 3, 2020, 2:47 p.m. UTC
... 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

Comments

Andrew Cooper Aug. 3, 2020, 4:40 p.m. UTC | #1
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).

~Andrew
Jan Beulich Aug. 4, 2020, 6:42 a.m. UTC | #2
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).

There are two zap_fpsel() in place there, which I would have thought
to cover this. I'll see whether I can repro on my Rome box.

Jan
Jan Beulich Aug. 4, 2020, 7:38 a.m. UTC | #3
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
Andrew Cooper Aug. 4, 2020, 2:59 p.m. UTC | #4
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.
>
> 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

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Ideally with the commit message for patch 3 adjusted.