QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
* ia-32/ia-64 fxsave64 instruction behavior when saving mmx
@ 2020-05-29 17:38 Robert Henry
  2020-05-31 23:22 ` Robert Henry
  0 siblings, 1 reply; 5+ messages in thread
From: Robert Henry @ 2020-05-29 17:38 UTC (permalink / raw)
  To: qemu-devel


[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ia-32/ia-64 fxsave64 instruction behavior when saving mmx
  2020-05-29 17:38 ia-32/ia-64 fxsave64 instruction behavior when saving mmx Robert Henry
@ 2020-05-31 23:22 ` Robert Henry
  2020-06-01  6:19   ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 5+ messages in thread
From: Robert Henry @ 2020-05-31 23:22 UTC (permalink / raw)
  To: qemu-devel


[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ia-32/ia-64 fxsave64 instruction behavior when saving mmx
  2020-05-31 23:22 ` Robert Henry
@ 2020-06-01  6:19   ` Philippe Mathieu-Daudé
  2020-07-31 20:34     ` Eduardo Habkost
  0 siblings, 1 reply; 5+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-01  6:19 UTC (permalink / raw)
  To: Robert Henry, qemu-devel, Paolo Bonzini, Richard Henderson,
	Eduardo Habkost

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.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ia-32/ia-64 fxsave64 instruction behavior when saving mmx
  2020-06-01  6:19   ` Philippe Mathieu-Daudé
@ 2020-07-31 20:34     ` Eduardo Habkost
  2020-07-31 21:19       ` [EXTERNAL] " Robert Henry
  0 siblings, 1 reply; 5+ messages in thread
From: Eduardo Habkost @ 2020-07-31 20:34 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Paolo Bonzini, qemu-devel, Robert Henry, Richard Henderson

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [EXTERNAL] Re: ia-32/ia-64 fxsave64 instruction behavior when saving mmx
  2020-07-31 20:34     ` Eduardo Habkost
@ 2020-07-31 21:19       ` Robert Henry
  0 siblings, 0 replies; 5+ messages in thread
From: Robert Henry @ 2020-07-31 21:19 UTC (permalink / raw)
  To: Eduardo Habkost, Philippe Mathieu-Daudé
  Cc: qemu-devel, Paolo Bonzini, Richard Henderson

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-29 17:38 ia-32/ia-64 fxsave64 instruction behavior when saving mmx Robert Henry
2020-05-31 23:22 ` Robert Henry
2020-06-01  6:19   ` Philippe Mathieu-Daudé
2020-07-31 20:34     ` Eduardo Habkost
2020-07-31 21:19       ` [EXTERNAL] " Robert Henry

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git