Re: [PATCH RESEND] x86: allow VEX et al encodings in 16-bit (protected) mode

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

On Tue, Jun 25, 2019 at 8:30 AM Jan Beulich <JBeulich@suse.com> wrote:
>
> >>> On 25.06.19 at 17:18, <hjl.tools@gmail.com> wrote:
> > On Tue, Jun 25, 2019 at 8:08 AM Jan Beulich <JBeulich@suse.com> wrote:
> >>
> >> >>> On 25.06.19 at 16:52, <hjl.tools@gmail.com> wrote:
> >> > On Tue, Jun 25, 2019 at 12:20 AM Jan Beulich <JBeulich@suse.com> wrote:
> >> >>
> >> >> >>> On 24.06.19 at 18:30, <hjl.tools@gmail.com> wrote:
> >> >> > On Mon, Jun 24, 2019 at 7:05 AM Jan Beulich <JBeulich@suse.com> wrote:
> >> >> >> --- a/gas/config/tc-i386.c
> >> >> >> +++ b/gas/config/tc-i386.c
> >> >> >> @@ -4387,9 +4387,9 @@ md_assemble (char *line)
> >> >> >>
> >> >> >>    if (is_any_vex_encoding (&i.tm))
> >> >> >>      {
> >> >> >> -      if (flag_code == CODE_16BIT)
> >> >> >> +      if (!cpu_arch_flags.bitfield.cpui286)
> >> >> >>         {
> >> >> >> -         as_bad (_("instruction `%s' isn't supported in 16-bit mode."),
> >> >> >> +         as_bad (_("instruction `%s' isn't supported outside of protected
> >> > mode."),
> >> >> >>                   i.tm.name);
> >> >> >>           return;
> >> >> >>         }
> >> >> >
> >> >> > flag_code == CODE_16BIT is used to indicate 16-bit mode, in most cases, for
> >> > real
> >> >> > mode.   If there are real use cases for VEX/EVEX insns in 16-bit protected
> >> > mode,
> >> >> > should we add a directive or pseudo prefix to indicate protected mode
> >> > encoding?
> >> >>
> >> >> Not sure - I'd leave that to you. All I want/need is to be able encode
> >> >> VEX/XOP/EVEX insns for 16-bit protected mode use. How about we go
> >> >> with this patch for now, and you further refine things to your liking
> >> >> subsequently?
> >> >>
> >> >
> >> > Up to now, flag_code == CODE_16BIT disallows VEX/EVEX encoding.
> >>
> >> And wrongly so, imo. Hence this patch.
> >>
> >> >  I
> >> > think VEX/EVEX encoding should be allowed only under a new directive.
> >>
> >> To be honest, I'm not really up to doing this work, not the least because
> >> I assume there might be other things that then ought to be made
> >> protected mode only (and I also wouldn't want to contribute a half baked
> >> implementation). Hence once again my suggestion: Let's go with this
> >> patch for now, and if you think things need to be restricted again a little
> >> more, you can follow up with a change implementing the new directive
> >> (and all its ramifications beyond VEX/EVEX handling, if any).
> >>
> >
> > Is there a real use case to use VEX/EVEX in 16-bit mode?
>
> Yes, I'd like to avoid having to use .byte in XenProject test cases. (That
> aside, it has been an actual bug from the very beginning to not allow
> these encodings in 16-bit mode. I can only assume it was a
> misunderstanding of the "no real or VM86 mode" constraint set forth by
> the SDM.)
>

OK.

Thanks.

-- 
H.J.