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
