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