From: "Cui, Lili" <lili.cui@intel.com>
To: "Beulich, Jan" <JBeulich@suse.com>
Cc: "Lu, Hongjiu" <hongjiu.lu@intel.com>,
"binutils@sourceware.org" <binutils@sourceware.org>
Subject: RE: [PATCH 1/8] Support APX GPR32 with rex2 prefix
Date: Wed, 27 Sep 2023 15:59:11 +0000 [thread overview]
Message-ID: <SJ0PR11MB560056EEC553901B3A33E8329EC2A@SJ0PR11MB5600.namprd11.prod.outlook.com> (raw)
In-Reply-To: <dba13b89-c458-f749-9aea-7e009d666a7b@suse.com>
> > /* Bits of REX we've already used. */
> > uint8_t rex_used;
> >
> > + /* REX2 prefix for the current instruction use gpr32(r16-r31). */
> > + unsigned char rex2;
> > + /* Bits of REX2 we've already used. */ unsigned char rex2_used;
>
> Since these two fields don't hold the REX2 bits directly, the comment(s)
> want(s) saying what they contain.
>
> > + unsigned char rex2_payload;
>
> I don't see this field used in more than one function. In which case it can be a
> local variable there (in the innermost scope covering all uses).
>
Yes, it should be local variable. Changed it.
> > @@ -367,6 +381,7 @@ fetch_error (const instr_info *ins)
> > #define PREFIX_IGNORED_DATA (PREFIX_DATA <<
> PREFIX_IGNORED_SHIFT)
> > #define PREFIX_IGNORED_ADDR (PREFIX_ADDR <<
> PREFIX_IGNORED_SHIFT)
> > #define PREFIX_IGNORED_LOCK (PREFIX_LOCK <<
> PREFIX_IGNORED_SHIFT)
> > +#define PREFIX_IGNORED_REX2 (PREFIX_REX2 <<
> PREFIX_IGNORED_SHIFT)
>
> I don't think "ignored" is what you mean, considering ...
>
> > /* MOD_0FAE_REG_5 */
> > - { "xrstor", { FXSAVE }, PREFIX_OPCODE },
> > + { "xrstor", { FXSAVE }, PREFIX_OPCODE |
> PREFIX_IGNORED_REX2 },
> > { PREFIX_TABLE (PREFIX_0FAE_REG_5_MOD_3) },
> > },
>
> ... these uses here.
>
Replaced " PREFIX_IGNORED_REX2" with "ILLEGAL_PREFIX_REX2 ".
> > case USE_EVEX_TABLE:
> > + if (ins->last_rex2_prefix >= 0)
> > + return &bad_opcode;
> > ins->two_source_ops = false;
> > /* EVEX prefix. */
> > ins->vex.evex = true;
>
> There aren't similar REX checks here, yet both should be handled as similarly
> as possible.
Done.
>
> > @@ -9292,13 +9344,17 @@ print_insn (bfd_vma pc, disassemble_info
> *info, int intel_syntax)
> > goto out;
> > }
> >
> > - if (*ins.codep == 0x0f)
> > + /* M0 in rex2 prefix represents map0 or map1. */ if (*ins.codep
> > + == 0x0f || (ins.rex2 & 0x8))
>
> Please can literals like the 0x8 here gain meaningful names (REX2_M in this
> case)?
>
Done.
> > @@ -9468,6 +9532,7 @@ print_insn (bfd_vma pc, disassemble_info *info,
> int intel_syntax)
> > ins.used_prefixes |= PREFIX_DATA;
> > /* Fall through. */
> > case PREFIX_OPCODE:
> > + case PREFIX_OPCODE | PREFIX_IGNORED_REX2:
>
> You may rather want to mask off the high part in the switch() expression itself.
Tried it , found that 'Case PREFIX_IGNORED' uses the high part of this switch.
#define PREFIX_IGNORED (PREFIX_IGNORED_REPZ \
| PREFIX_IGNORED_REPNZ \
| PREFIX_IGNORED_DATA)
#define PREFIX_IGNORED_REPZ (PREFIX_REPZ << PREFIX_IGNORED_SHIFT)
#define PREFIX_IGNORED_REPNZ (PREFIX_REPNZ << PREFIX_IGNORED_SHIFT)
#define PREFIX_IGNORED_DATA (PREFIX_DATA << PREFIX_IGNORED_SHIFT)
> > @@ -9510,9 +9575,17 @@ print_insn (bfd_vma pc, disassemble_info *info,
> > int intel_syntax)
> >
> > /* Check if the REX prefix is used. */
> > if ((ins.rex ^ ins.rex_used) == 0
> > - && !ins.need_vex && ins.last_rex_prefix >= 0)
> > + && !ins.need_vex && ins.last_rex_prefix >= 0
> > + && ins.last_rex2_prefix < 0)
> > ins.all_prefixes[ins.last_rex_prefix] = 0;
> >
> > + /* Check if the REX2 prefix is used. */
> > + if (ins.last_rex2_prefix >= 0
> > + && ((((ins.rex2 & 0x7) ^ (ins.rex2_used & 0x7)) == 0
> > + && (ins.rex2 & 0x7))
> > + || dp == &bad_opcode))
> > + ins.all_prefixes[ins.last_rex2_prefix] = 0;
>
> I'm again puzzled by the dissimilarity with the REX handling. Furthermore,
> with the way you split the REX2 payload byte, I don't think the combination of
> REX and REX2 handling above will result in correct output in all cases.
> (There shouldn't be mention of an unused REX bit when REX2 was in use on
> an insn.)
Done.
> > @@ -11307,6 +11386,7 @@ static bool
> > OP_E_memory (instr_info *ins, int bytemode, int sizeflag) {
> > int add = (ins->rex & REX_B) ? 8 : 0;
> > + add += (ins->rex2 & REX_B) ? 16 : 0;
> > int riprel = 0;
> > int shift;
>
> While generally mixing declaration and statements is okay nowadays, putting
> a statement in the middle of a block's initial declarations would imo still
> better be avoided.
Done.
Moved this comment from patch2/8 to here.
if (modifiers[Vex].value
|| (space > SPACE_0F
&& space != SPACE_EVEXMAP4
&& !modifiers[EVex].value
&& !modifiers[Disp8MemShift].value
&& !modifiers[Broadcast].value
&& !modifiers[Masking].value
&& !modifiers[SAE].value))
}
modifiers[No_egpr].value = 1;
}
>And then - shouldn't at least part of this already be put in place in patch 1?
>Finally, to avoid the split between where this attribute gets set, wouldn't it be possible to also handle the XSAVE/XRSTOR variants here rather than directly in the opcode table?
I put part of this in patch 1, and add a new function to handle NoEgpr (the parameter's number of process_i386_opcode_modifier is a bit too much, so I added a new function).
I merged partII patch2/6 into this patch. listed it with 3.
We handle the following in function if_entry_needs_special_handle():
1. Prefixing XSAVE* and XRSTOR* instructions with REX2 triggers #UD.
2. Disable Egpr for 3dnow and 3dnowA.
3. All opcodes listed map0 0x4*, 0x7*, 0xa* and map0 0x3*, 0x8* are reserved under REX2 and triggers #UD when prefixed with REX2
Finally, thank you for checking these large patches so carefully. The next few days are China's national holidays, which last about 8 days, my feedback time will be longer. Thank you.
Lili.
> Jan
next prev parent reply other threads:[~2023-09-27 15:59 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 15:25 [PATCH 0/8] [RFC] Support Intel APX EGPR Cui, Lili
2023-09-19 15:25 ` [PATCH 1/8] Support APX GPR32 with rex2 prefix Cui, Lili
2023-09-21 15:27 ` Jan Beulich
2023-09-27 15:57 ` Cui, Lili
2023-09-21 15:51 ` Jan Beulich
2023-09-27 15:59 ` Cui, Lili [this message]
2023-09-28 8:02 ` Jan Beulich
2023-10-07 3:27 ` Cui, Lili
2023-09-19 15:25 ` [PATCH 2/8] Support APX GPR32 with extend evex prefix Cui, Lili
2023-09-22 10:12 ` Jan Beulich
2023-10-17 15:48 ` Cui, Lili
2023-10-18 6:40 ` Jan Beulich
2023-10-18 10:44 ` Cui, Lili
2023-10-18 10:50 ` Jan Beulich
2023-09-22 10:50 ` Jan Beulich
2023-10-17 15:50 ` Cui, Lili
2023-10-17 16:11 ` Jan Beulich
2023-10-18 2:02 ` Cui, Lili
2023-10-18 6:10 ` Jan Beulich
2023-09-25 6:03 ` Jan Beulich
2023-10-17 15:52 ` Cui, Lili
2023-10-17 16:12 ` Jan Beulich
2023-10-18 6:31 ` Cui, Lili
2023-10-18 6:47 ` Jan Beulich
2023-10-18 7:52 ` Cui, Lili
2023-10-18 8:21 ` Jan Beulich
2023-10-18 11:30 ` Cui, Lili
2023-10-19 11:58 ` Cui, Lili
2023-10-19 15:24 ` Jan Beulich
2023-10-19 16:38 ` Cui, Lili
2023-10-20 6:25 ` Jan Beulich
2023-10-22 14:33 ` Cui, Lili
2023-09-19 15:25 ` [PATCH 3/8] Add tests for " Cui, Lili
2023-09-27 13:11 ` Jan Beulich
2023-10-17 15:53 ` FW: " Cui, Lili
2023-10-17 16:19 ` Jan Beulich
2023-10-18 2:32 ` Cui, Lili
2023-10-18 6:05 ` Jan Beulich
2023-10-18 7:16 ` Cui, Lili
2023-10-18 8:05 ` Jan Beulich
2023-10-18 11:26 ` Cui, Lili
2023-10-18 12:06 ` Jan Beulich
2023-10-25 16:03 ` Cui, Lili
2023-09-27 13:19 ` Jan Beulich
2023-09-19 15:25 ` [PATCH 4/8] Support APX NDD Cui, Lili
2023-09-27 14:44 ` Jan Beulich
2023-10-22 14:05 ` Cui, Lili
2023-10-23 7:12 ` Jan Beulich
2023-10-25 8:10 ` Cui, Lili
2023-10-25 8:47 ` Jan Beulich
2023-10-25 15:49 ` Cui, Lili
2023-10-25 15:59 ` Jan Beulich
2023-09-28 7:57 ` Jan Beulich
2023-10-22 14:57 ` Cui, Lili
2023-10-24 11:39 ` Cui, Lili
2023-10-24 11:58 ` Jan Beulich
2023-10-25 15:29 ` Cui, Lili
2023-09-19 15:25 ` [PATCH 5/8] Support APX NDD optimized encoding Cui, Lili
2023-09-28 9:29 ` Jan Beulich
2023-10-23 2:57 ` Hu, Lin1
2023-10-23 7:23 ` Jan Beulich
2023-10-23 7:50 ` Hu, Lin1
2023-10-23 8:15 ` Jan Beulich
2023-10-24 1:40 ` Hu, Lin1
2023-10-24 6:03 ` Jan Beulich
2023-10-24 6:08 ` Hu, Lin1
2023-10-23 3:07 ` [PATCH-V2] " Hu, Lin1
2023-10-23 3:30 ` [PATCH 5/8] [v2] " Hu, Lin1
2023-10-23 7:26 ` Jan Beulich
2023-09-19 15:25 ` [PATCH 6/8] Support APX Push2/Pop2 Cui, Lili
2023-09-28 11:37 ` Jan Beulich
2023-10-30 15:21 ` Cui, Lili
2023-10-30 15:31 ` Jan Beulich
2023-11-20 13:05 ` Cui, Lili
2023-09-19 15:25 ` [PATCH 7/8] Support APX NF Cui, Lili
2023-09-25 6:07 ` Jan Beulich
2023-09-28 12:42 ` Jan Beulich
2023-11-02 10:15 ` Cui, Lili
2023-11-02 10:23 ` Jan Beulich
2023-11-02 10:46 ` Cui, Lili
2023-12-12 2:59 ` H.J. Lu
2023-09-19 15:25 ` [PATCH 8/8] Support APX JMPABS Cui, Lili
2023-09-28 13:11 ` Jan Beulich
2023-11-02 2:32 ` Hu, Lin1
2023-11-02 11:29 [PATCH v2 0/8] Support Intel APX EGPR Cui, Lili
2023-11-02 11:29 ` [PATCH 1/8] Support APX GPR32 with rex2 prefix Cui, Lili
2023-11-02 17:05 ` Jan Beulich
2023-11-03 6:20 ` Cui, Lili
2023-11-03 13:05 ` Jan Beulich
2023-11-03 14:19 ` Jan Beulich
2023-11-06 15:20 ` Cui, Lili
2023-11-06 16:08 ` Jan Beulich
2023-11-07 8:16 ` Cui, Lili
2023-11-07 10:43 ` Jan Beulich
2023-11-07 15:31 ` Cui, Lili
2023-11-07 15:43 ` Jan Beulich
2023-11-07 15:53 ` Cui, Lili
2023-11-06 15:02 ` Jan Beulich
2023-11-07 8:06 ` Cui, Lili
2023-11-07 10:20 ` Jan Beulich
2023-11-07 14:32 ` Cui, Lili
2023-11-07 15:08 ` Jan Beulich
2023-11-06 15:39 ` Jan Beulich
2023-11-09 8:02 ` Cui, Lili
2023-11-09 10:52 ` Jan Beulich
2023-11-09 13:27 ` Cui, Lili
2023-11-09 15:22 ` Jan Beulich
2023-11-10 7:11 ` Cui, Lili
2023-11-10 9:14 ` Jan Beulich
2023-11-10 9:21 ` Jan Beulich
2023-11-10 12:38 ` Cui, Lili
2023-12-14 10:13 ` Cui, Lili
2023-12-18 15:24 ` Jan Beulich
2023-12-18 16:23 ` H.J. Lu
2023-11-10 9:47 ` Cui, Lili
2023-11-10 9:57 ` Jan Beulich
2023-11-10 12:05 ` Cui, Lili
2023-11-10 12:35 ` Jan Beulich
2023-11-13 0:18 ` Cui, Lili
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR11MB560056EEC553901B3A33E8329EC2A@SJ0PR11MB5600.namprd11.prod.outlook.com \
--to=lili.cui@intel.com \
--cc=JBeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hongjiu.lu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).