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

[Jan Beulich <jbeulich@xxxxxxxx>]

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