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 <pbonz...@redhat.com> (maintainer:X86 TCG CPUs) > Richard Henderson <r...@twiddle.net> (maintainer:X86 TCG CPUs) > Eduardo Habkost <ehabk...@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