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

Jan Beulich jbeulich@suse.com
Thu Nov 14 07:12:00 GMT 2019


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



More information about the Binutils mailing list