[RFC] x86: SYSENTER/SYSEXIT are unavailable in 64-bit mode on AMD

Message ID 4fb39967-31dd-ed6d-0fad-425e5f2a012d@suse.com
State New
Headers show
Series
  • [RFC] x86: SYSENTER/SYSEXIT are unavailable in 64-bit mode on AMD
Related show

Commit Message

Jan Beulich Nov. 11, 2019, 12:01 p.m.
opcodes/
2019-11-XX  Jan Beulich  <jbeulich@suse.com>

	* i386-opc.tbl (sysenter, sysexit): Split into AMD64 and Intel64
	forms.
	* i386-tbl.h: Re-generate.
---
RFC because this is liable to cause problems for existing code, but I
think we should still correct this. We may want to have a directive
(besides the command line option) such that the accepted ISA can be
overridden in a more fine granular manner.

Comments

H.J. Lu Nov. 11, 2019, 5:12 p.m. | #1
On Mon, Nov 11, 2019 at 4:01 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> opcodes/

> 2019-11-XX  Jan Beulich  <jbeulich@suse.com>

>

>         * i386-opc.tbl (sysenter, sysexit): Split into AMD64 and Intel64

>         forms.

>         * i386-tbl.h: Re-generate.

> ---

> RFC because this is liable to cause problems for existing code, but I

> think we should still correct this. We may want to have a directive

> (besides the command line option) such that the accepted ISA can be

> overridden in a more fine granular manner.


I think it is an overkill.

> --- a/opcodes/i386-opc.tbl

> +++ b/opcodes/i386-opc.tbl

> @@ -891,8 +891,10 @@ rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu

>  cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }

>

>  // Pentium II/Pentium Pro extensions.

> -sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> -sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> +sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> +sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> +sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> +sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>  fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

>  fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }

>  fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }


Are there any usages in 64-bit mode?  If not, just disallow them in 64-bit mode.

-- 
H.J.
Jan Beulich Nov. 12, 2019, 7:13 a.m. | #2
On 11.11.2019 18:12,  H.J. Lu  wrote:
> On Mon, Nov 11, 2019 at 4:01 AM Jan Beulich <jbeulich@suse.com> wrote:

>> RFC because this is liable to cause problems for existing code, but I

>> think we should still correct this. We may want to have a directive

>> (besides the command line option) such that the accepted ISA can be

>> overridden in a more fine granular manner.

> 

> I think it is an overkill.


Well, even better if this means you're fine with the patch as is
(seeing that below you're even suggesting a more rigid approach).

>> --- a/opcodes/i386-opc.tbl

>> +++ b/opcodes/i386-opc.tbl

>> @@ -891,8 +891,10 @@ rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu

>>  cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }

>>

>>  // Pentium II/Pentium Pro extensions.

>> -sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>> -sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>> +sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>> +sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>> +sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>> +sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>  fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

>>  fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }

>>  fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

> 

> Are there any usages in 64-bit mode?  If not, just disallow them in 64-bit mode.


Usages - I don't know. But I do know that they're usable.

Jan
H.J. Lu Nov. 12, 2019, 8:26 p.m. | #3
On Mon, Nov 11, 2019 at 11:13 PM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 11.11.2019 18:12,  H.J. Lu  wrote:

> > On Mon, Nov 11, 2019 at 4:01 AM Jan Beulich <jbeulich@suse.com> wrote:

> >> RFC because this is liable to cause problems for existing code, but I

> >> think we should still correct this. We may want to have a directive

> >> (besides the command line option) such that the accepted ISA can be

> >> overridden in a more fine granular manner.

> >

> > I think it is an overkill.

>

> Well, even better if this means you're fine with the patch as is

> (seeing that below you're even suggesting a more rigid approach).

>

> >> --- a/opcodes/i386-opc.tbl

> >> +++ b/opcodes/i386-opc.tbl

> >> @@ -891,8 +891,10 @@ rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu

> >>  cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }

> >>

> >>  // Pentium II/Pentium Pro extensions.

> >> -sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >> -sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >> +sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >> +sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >> +sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >> +sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>  fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

> >>  fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }

> >>  fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

> >

> > Are there any usages in 64-bit mode?  If not, just disallow them in 64-bit mode.

>

> Usages - I don't know. But I do know that they're usable.

>


They can use REX.W prefix if needed.

-- 
H.J.
Jan Beulich Nov. 13, 2019, 1:18 p.m. | #4
On 12.11.2019 21:26,  H.J. Lu  wrote:
> On Mon, Nov 11, 2019 at 11:13 PM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 11.11.2019 18:12,  H.J. Lu  wrote:

>>> On Mon, Nov 11, 2019 at 4:01 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>> RFC because this is liable to cause problems for existing code, but I

>>>> think we should still correct this. We may want to have a directive

>>>> (besides the command line option) such that the accepted ISA can be

>>>> overridden in a more fine granular manner.

>>>

>>> I think it is an overkill.

>>

>> Well, even better if this means you're fine with the patch as is

>> (seeing that below you're even suggesting a more rigid approach).

>>

>>>> --- a/opcodes/i386-opc.tbl

>>>> +++ b/opcodes/i386-opc.tbl

>>>> @@ -891,8 +891,10 @@ rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu

>>>>  cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }

>>>>

>>>>  // Pentium II/Pentium Pro extensions.

>>>> -sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>> -sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>> +sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>> +sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>> +sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>> +sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>  fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

>>>>  fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }

>>>>  fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

>>>

>>> Are there any usages in 64-bit mode?  If not, just disallow them in 64-bit mode.

>>

>> Usages - I don't know. But I do know that they're usable.

> 

> They can use REX.W prefix if needed.


How does use (or not) of REX.W relate to whether or not to allow the insns
in 64-bit mode? There's nothing to add REX.W to if the insns wouldn't be
accepted by gas. (As an aside, I don't think REX.W matters for these insns
in any way.)

Jan
H.J. Lu Nov. 13, 2019, 9:07 p.m. | #5
On Wed, Nov 13, 2019 at 5:18 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 12.11.2019 21:26,  H.J. Lu  wrote:

> > On Mon, Nov 11, 2019 at 11:13 PM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 11.11.2019 18:12,  H.J. Lu  wrote:

> >>> On Mon, Nov 11, 2019 at 4:01 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>> RFC because this is liable to cause problems for existing code, but I

> >>>> think we should still correct this. We may want to have a directive

> >>>> (besides the command line option) such that the accepted ISA can be

> >>>> overridden in a more fine granular manner.

> >>>

> >>> I think it is an overkill.

> >>

> >> Well, even better if this means you're fine with the patch as is

> >> (seeing that below you're even suggesting a more rigid approach).

> >>

> >>>> --- a/opcodes/i386-opc.tbl

> >>>> +++ b/opcodes/i386-opc.tbl

> >>>> @@ -891,8 +891,10 @@ rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu

> >>>>  cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }

> >>>>

> >>>>  // Pentium II/Pentium Pro extensions.

> >>>> -sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>> -sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>> +sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>> +sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>> +sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>> +sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>  fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

> >>>>  fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }

> >>>>  fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

> >>>

> >>> Are there any usages in 64-bit mode?  If not, just disallow them in 64-bit mode.

> >>

> >> Usages - I don't know. But I do know that they're usable.

> >

> > They can use REX.W prefix if needed.

>

> How does use (or not) of REX.W relate to whether or not to allow the insns

> in 64-bit mode? There's nothing to add REX.W to if the insns wouldn't be

> accepted by gas. (As an aside, I don't think REX.W matters for these insns

> in any way.)

>


REX.W is unrelated.  .byte can be used in 64-bit mode to encode them.


-- 
H.J.
Jan Beulich Nov. 14, 2019, 7:12 a.m. | #6
On 13.11.2019 22:07,  H.J. Lu  wrote:
> On Wed, Nov 13, 2019 at 5:18 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 12.11.2019 21:26,  H.J. Lu  wrote:

>>> On Mon, Nov 11, 2019 at 11:13 PM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 11.11.2019 18:12,  H.J. Lu  wrote:

>>>>> On Mon, Nov 11, 2019 at 4:01 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>> RFC because this is liable to cause problems for existing code, but I

>>>>>> think we should still correct this. We may want to have a directive

>>>>>> (besides the command line option) such that the accepted ISA can be

>>>>>> overridden in a more fine granular manner.

>>>>>

>>>>> I think it is an overkill.

>>>>

>>>> Well, even better if this means you're fine with the patch as is

>>>> (seeing that below you're even suggesting a more rigid approach).

>>>>

>>>>>> --- a/opcodes/i386-opc.tbl

>>>>>> +++ b/opcodes/i386-opc.tbl

>>>>>> @@ -891,8 +891,10 @@ rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu

>>>>>>  cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }

>>>>>>

>>>>>>  // Pentium II/Pentium Pro extensions.

>>>>>> -sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>> -sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>> +sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>> +sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>> +sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>> +sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>>  fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

>>>>>>  fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }

>>>>>>  fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

>>>>>

>>>>> Are there any usages in 64-bit mode?  If not, just disallow them in 64-bit mode.

>>>>

>>>> Usages - I don't know. But I do know that they're usable.

>>>

>>> They can use REX.W prefix if needed.

>>

>> How does use (or not) of REX.W relate to whether or not to allow the insns

>> in 64-bit mode? There's nothing to add REX.W to if the insns wouldn't be

>> accepted by gas. (As an aside, I don't think REX.W matters for these insns

>> in any way.)

>>

> 

> REX.W is unrelated.  .byte can be used in 64-bit mode to encode them.


That's a joke, I hope? Or else why don't we drop this and other insns
(say all ones without operands) altogether?

Jan
H.J. Lu Nov. 14, 2019, 7:31 p.m. | #7
On Wed, Nov 13, 2019 at 11:12 PM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 13.11.2019 22:07,  H.J. Lu  wrote:

> > On Wed, Nov 13, 2019 at 5:18 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 12.11.2019 21:26,  H.J. Lu  wrote:

> >>> On Mon, Nov 11, 2019 at 11:13 PM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> On 11.11.2019 18:12,  H.J. Lu  wrote:

> >>>>> On Mon, Nov 11, 2019 at 4:01 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>> RFC because this is liable to cause problems for existing code, but I

> >>>>>> think we should still correct this. We may want to have a directive

> >>>>>> (besides the command line option) such that the accepted ISA can be

> >>>>>> overridden in a more fine granular manner.

> >>>>>

> >>>>> I think it is an overkill.

> >>>>

> >>>> Well, even better if this means you're fine with the patch as is

> >>>> (seeing that below you're even suggesting a more rigid approach).

> >>>>

> >>>>>> --- a/opcodes/i386-opc.tbl

> >>>>>> +++ b/opcodes/i386-opc.tbl

> >>>>>> @@ -891,8 +891,10 @@ rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu

> >>>>>>  cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }

> >>>>>>

> >>>>>>  // Pentium II/Pentium Pro extensions.

> >>>>>> -sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>> -sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>> +sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>> +sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>> +sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>> +sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>>  fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

> >>>>>>  fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }

> >>>>>>  fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

> >>>>>

> >>>>> Are there any usages in 64-bit mode?  If not, just disallow them in 64-bit mode.

> >>>>

> >>>> Usages - I don't know. But I do know that they're usable.

> >>>

> >>> They can use REX.W prefix if needed.

> >>

> >> How does use (or not) of REX.W relate to whether or not to allow the insns

> >> in 64-bit mode? There's nothing to add REX.W to if the insns wouldn't be

> >> accepted by gas. (As an aside, I don't think REX.W matters for these insns

> >> in any way.)

> >>

> >

> > REX.W is unrelated.  .byte can be used in 64-bit mode to encode them.

>

> That's a joke, I hope? Or else why don't we drop this and other insns

> (say all ones without operands) altogether?


If you want to properly support them, you also need to adjust "objdump":

  amd64       Display instruction in AMD64 ISA
  intel64     Display instruction in Intel64 ISA

-- 
H.J.
Jan Beulich Nov. 15, 2019, 8:52 a.m. | #8
On 14.11.2019 20:31,  H.J. Lu  wrote:
> On Wed, Nov 13, 2019 at 11:12 PM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 13.11.2019 22:07,  H.J. Lu  wrote:

>>> On Wed, Nov 13, 2019 at 5:18 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 12.11.2019 21:26,  H.J. Lu  wrote:

>>>>> On Mon, Nov 11, 2019 at 11:13 PM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>

>>>>>> On 11.11.2019 18:12,  H.J. Lu  wrote:

>>>>>>> On Mon, Nov 11, 2019 at 4:01 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>>> RFC because this is liable to cause problems for existing code, but I

>>>>>>>> think we should still correct this. We may want to have a directive

>>>>>>>> (besides the command line option) such that the accepted ISA can be

>>>>>>>> overridden in a more fine granular manner.

>>>>>>>

>>>>>>> I think it is an overkill.

>>>>>>

>>>>>> Well, even better if this means you're fine with the patch as is

>>>>>> (seeing that below you're even suggesting a more rigid approach).

>>>>>>

>>>>>>>> --- a/opcodes/i386-opc.tbl

>>>>>>>> +++ b/opcodes/i386-opc.tbl

>>>>>>>> @@ -891,8 +891,10 @@ rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu

>>>>>>>>  cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }

>>>>>>>>

>>>>>>>>  // Pentium II/Pentium Pro extensions.

>>>>>>>> -sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>>>> -sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>>>> +sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>>>> +sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>>>> +sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>>>> +sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

>>>>>>>>  fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

>>>>>>>>  fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }

>>>>>>>>  fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

>>>>>>>

>>>>>>> Are there any usages in 64-bit mode?  If not, just disallow them in 64-bit mode.

>>>>>>

>>>>>> Usages - I don't know. But I do know that they're usable.

>>>>>

>>>>> They can use REX.W prefix if needed.

>>>>

>>>> How does use (or not) of REX.W relate to whether or not to allow the insns

>>>> in 64-bit mode? There's nothing to add REX.W to if the insns wouldn't be

>>>> accepted by gas. (As an aside, I don't think REX.W matters for these insns

>>>> in any way.)

>>>>

>>>

>>> REX.W is unrelated.  .byte can be used in 64-bit mode to encode them.

>>

>> That's a joke, I hope? Or else why don't we drop this and other insns

>> (say all ones without operands) altogether?

> 

> If you want to properly support them, you also need to adjust "objdump":

> 

>   amd64       Display instruction in AMD64 ISA

>   intel64     Display instruction in Intel64 ISA


That'll require more extensive changes to the disassembler. I definitely
don't want to end up not decoding them (as if they were invalid) in
default mode (i.e. neither -Mamd64 nor -Mintel64 specified). But if
that's what you want, I can certainly add a disassembler side equivalent
to the change.

Jan
H.J. Lu Nov. 15, 2019, 6:17 p.m. | #9
On Fri, Nov 15, 2019 at 12:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 14.11.2019 20:31,  H.J. Lu  wrote:

> > On Wed, Nov 13, 2019 at 11:12 PM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 13.11.2019 22:07,  H.J. Lu  wrote:

> >>> On Wed, Nov 13, 2019 at 5:18 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> On 12.11.2019 21:26,  H.J. Lu  wrote:

> >>>>> On Mon, Nov 11, 2019 at 11:13 PM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>

> >>>>>> On 11.11.2019 18:12,  H.J. Lu  wrote:

> >>>>>>> On Mon, Nov 11, 2019 at 4:01 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>>> RFC because this is liable to cause problems for existing code, but I

> >>>>>>>> think we should still correct this. We may want to have a directive

> >>>>>>>> (besides the command line option) such that the accepted ISA can be

> >>>>>>>> overridden in a more fine granular manner.

> >>>>>>>

> >>>>>>> I think it is an overkill.

> >>>>>>

> >>>>>> Well, even better if this means you're fine with the patch as is

> >>>>>> (seeing that below you're even suggesting a more rigid approach).

> >>>>>>

> >>>>>>>> --- a/opcodes/i386-opc.tbl

> >>>>>>>> +++ b/opcodes/i386-opc.tbl

> >>>>>>>> @@ -891,8 +891,10 @@ rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu

> >>>>>>>>  cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }

> >>>>>>>>

> >>>>>>>>  // Pentium II/Pentium Pro extensions.

> >>>>>>>> -sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>>>> -sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>>>> +sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>>>> +sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>>>> +sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>>>> +sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

> >>>>>>>>  fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

> >>>>>>>>  fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }

> >>>>>>>>  fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

> >>>>>>>

> >>>>>>> Are there any usages in 64-bit mode?  If not, just disallow them in 64-bit mode.

> >>>>>>

> >>>>>> Usages - I don't know. But I do know that they're usable.

> >>>>>

> >>>>> They can use REX.W prefix if needed.

> >>>>

> >>>> How does use (or not) of REX.W relate to whether or not to allow the insns

> >>>> in 64-bit mode? There's nothing to add REX.W to if the insns wouldn't be

> >>>> accepted by gas. (As an aside, I don't think REX.W matters for these insns

> >>>> in any way.)

> >>>>

> >>>

> >>> REX.W is unrelated.  .byte can be used in 64-bit mode to encode them.

> >>

> >> That's a joke, I hope? Or else why don't we drop this and other insns

> >> (say all ones without operands) altogether?

> >

> > If you want to properly support them, you also need to adjust "objdump":

> >

> >   amd64       Display instruction in AMD64 ISA

> >   intel64     Display instruction in Intel64 ISA

>

> That'll require more extensive changes to the disassembler. I definitely

> don't want to end up not decoding them (as if they were invalid) in

> default mode (i.e. neither -Mamd64 nor -Mintel64 specified). But if

> that's what you want, I can certainly add a disassembler side equivalent

> to the change.

>


To make your change complete, we need both assembler and disassembler
changes with a 64-bit testcase.


-- 
H.J.

Patch

--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -891,8 +891,10 @@  rdmsr, 0, 0xf32, None, 2, Cpu586, No_bSu
 cmpxchg8b, 1, 0xfc7, 0x1, 2, Cpu586, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|IsLockable|NoRex64|HLEPrefixOk, { Qword|Unspecified|BaseIndex }
 
 // Pentium II/Pentium Pro extensions.
-sysenter, 0, 0xf34, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
-sysexit, 0, 0xf35, None, 2, Cpu686, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
+sysenter, 0, 0xf34, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
+sysenter, 0, 0xf34, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
+sysexit, 0, 0xf35, None, 2, Cpu686, Intel64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
+sysexit, 0, 0xf35, None, 2, Cpu686|CpuNo64, AMD64|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
 fxsave, 1, 0xfae, 0x0, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }
 fxsave64, 1, 0xfae, 0x0, 2, CpuFXSR|Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Unspecified|BaseIndex }
 fxrstor, 1, 0xfae, 0x1, 2, CpuFXSR, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }