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

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.