Re: ia-32/ia-64 fxsave64 instruction behavior when saving mmx

[Eduardo Habkost <ehabkost@redhat.com>]

On Mon, Jun 01, 2020 at 08:19:51AM +0200, Philippe Mathieu-Daudé wrote:
> Hi Robert.
> 
> Top-posting is difficult to read on technical lists,
> it's better to reply inline.
> 
> Cc'ing the X86 FPU maintainers:
> 
> ./scripts/get_maintainer.pl -f target/i386/fpu_helper.c
> Paolo Bonzini <pbonzini@redhat.com> (maintainer:X86 TCG CPUs)
> Richard Henderson <rth@twiddle.net> (maintainer:X86 TCG CPUs)
> Eduardo Habkost <ehabkost@redhat.com> (maintainer:X86 TCG CPUs)
> 
> On 6/1/20 1:22 AM, Robert Henry wrote:
> > Here's additional information.
> > 
> > All of the remill tests of the legacy MMX instructions fail. These
> > instructions work on 64-bit registers aliased with the lower 64-bits of
> > the x87 fp80 registers.  The tests fail because remill expects the
> > fxsave64 instruction to deliver 16 bits of 1's (infinity or nan prefix)
> > in the fp80 exponent, eg bits 79:64.  Metal does this, but QEMU does not.
> 
> Metal is what matters, QEMU should emulate it when possible.
> 
> > 
> > Reading of Intel Software development manual, table 3.44
> > (https://www.felixcloutier.com/x86/FXSAVE.html#tbl-3-44) says these 16
> > bits are reserved, but another version of the manual
> > (http://math-atlas.sourceforge.net/devel/arch/ia32_arch.pdf) section
> > 9.6.2 "Transitions between x87 fpu and mmx code" says a write to an MMX
> > register sets those 16 bits to all 1s.
> 
> You are [1] here answering [2] you asked below.
> 
> > 
> > In digging through the code for the implementation of the SSE/mmx
> > instruction pavgb I see a nice clean implementation in the SSE_HELPER_B
> > macro which takes a MMXREG which is an MMREG_UNION which does not
> > provide, to the extent that I can figure this out, a handle to bits
> > 79:64 of the aliased-with x87 register.
> > 
> > I find it hard to believe that an apparent bug like this has been here
> > "forever". Am I missing something?
> 
> Likely the developer who implemented this code didn't have all the
> information you found, nor the test-suite, and eventually not even the
> hardware to compare.
> 
> Since you have a good understanding of Intel FPU and hardware to
> compare, do you mind sending a patch to have QEMU emulate the correct
> hardware behavior?
> 
> If possible add a test case to tests/tcg/i386/test-i386.c (see
> test_fxsave there).

Was this issue addressed, or does it remain unfixed?  I remember
seeing x86 FPU patches merged recently, but I don't know if they
were related to this.

> 
> > 
> > Robert Henry
> > ------------------------------------------------------------------------
> > *From:* Robert Henry
> > *Sent:* Friday, May 29, 2020 10:38 AM
> > *To:* qemu-devel@nongnu.org <qemu-devel@nongnu.org>
> > *Subject:* ia-32/ia-64 fxsave64 instruction behavior when saving mmx
> >  
> > Background: The ia-32/ia-64 fxsave64 instruction saves fp80 or legacy
> > SSE mmx registers. The mmx registers are saved as if they were fp80
> > values. The lower 64 bits of the constructed fp80 value is the mmx
> > register.  The upper 16 bits of the constructed fp80 value are reserved;
> > see the last row of table 3-44
> > of https://www.felixcloutier.com/x86/fxsave#tbl-3-44
> > 
> > The Intel core i9-9980XE Skylake metal I have puts 0xffff into these
> > reserved 16 bits when saving MMX.
> > 
> > QEMU appears to put 0's there.
> > 
> > Does anybody have insight as to what "reserved" really means, or must
> > be, in this case?
> 
> You self-answered to this [2] in [1] earlier.
> 
> > I take the verb "reserved" to mean something other
> > than "undefined".
> > 
> > I came across this issue when running the remill instruction test
> > engine.  See my
> > issue https://github.com/lifting-bits/remill/issues/423 For better or
> > worse, remill assumes that those bits are 0xffff, not 0x0000
> > 
> 
> Regards,
> 
> Phil.
> 

-- 
Eduardo