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

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

[Robert Henry]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

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?  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


[-- Attachment #2: Type: text/html, Size: 2534 bytes --]

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

[Robert Henry]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

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.

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.

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?

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?  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


[-- Attachment #2: Type: text/html, Size: 4640 bytes --]

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

[Philippe Mathieu-Daudé]

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).

> 
> 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.

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

[Eduardo Habkost]

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

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

[Robert Henry]

On 7/31/20 1:34 PM, Eduardo Habkost wrote:
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.felixcloutier.com%2Fx86%2FFXSAVE.html%23tbl-3-44&amp;data=02%7C01%7Crobhenry%40microsoft.com%7C56b85c84b7234f16f07c08d8359125bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318245390249551&amp;sdata=8CFUNe%2F%2BbLyukyV6BmmTBFyoV%2B3pTFh%2Bg5QAs3ccLbc%3D&amp;reserved=0) says these 16
>>> bits are reserved, but another version of the manual
>>> (https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmath-atlas.sourceforge.net%2Fdevel%2Farch%2Fia32_arch.pdf&amp;data=02%7C01%7Crobhenry%40microsoft.com%7C56b85c84b7234f16f07c08d8359125bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318245390249551&amp;sdata=2SiKu1cx4SVhwzzSbj7hgz%2B8ICCZHDnu0npUs9yMJLA%3D&amp;reserved=0) 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.
>
I haven't done anything to address this issue.
>>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.felixcloutier.com%2Fx86%2Ffxsave%23tbl-3-44&amp;data=02%7C01%7Crobhenry%40microsoft.com%7C56b85c84b7234f16f07c08d8359125bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318245390249551&amp;sdata=0CBE%2Btnm2b%2FJu9FjNHHjuh5vrYJ2MTfkitMApxXRSZQ%3D&amp;reserved=0
>>>
>>> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flifting-bits%2Fremill%2Fissues%2F423%25C3%2583&amp;data=02%7C01%7Crobhenry%40microsoft.com%7C56b85c84b7234f16f07c08d8359125bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318245390249551&amp;sdata=BjW7gZplqoUlKdpOT7dRnCvlzTrC4Vgpy%2BFf8bNpT0k%3D&amp;reserved=0, For better or
>>> worse, remill assumes that those bits are 0xffff, not 0x0000
>>>
>> Regards,
>>
>> Phil.
>>