From: Jan Beulich <jbeulich@suse.com>
To: "Hu, Lin1" <lin1.hu@intel.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>,
"Lu, Hongjiu" <hongjiu.lu@intel.com>
Subject: Re: [PATCH] Support Intel USER_MSR
Date: Tue, 24 Oct 2023 14:02:16 +0200 [thread overview]
Message-ID: <5c3a3d73-0f73-1941-ab31-6ad95050210e@suse.com> (raw)
In-Reply-To: <SJ0PR11MB5940BE3F6DB357801D367C0BA6DFA@SJ0PR11MB5940.namprd11.prod.outlook.com>
On 24.10.2023 12:01, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Tuesday, October 24, 2023 4:56 PM
>>
>> On 24.10.2023 10:38, Hu, Lin1 wrote:
>>> I've thought of it so far is I can use a Fixup function like
>>>
>>> static bool
>>> uwrmsr_Fixup (instr_info *ins, int bytemode, int sizeflag) {
>>> if (bytemode == d_mode)
>>> {
>>> if (OP_Skip_MODRM (ins, 0, sizeflag))
>>> {
>>> if (OP_I (ins, bytemode, sizeflag))
>>> {
>>> ins->codep--;
>>> }
>>> return true;
>>> }
>>> }
>>> return false;
>>> }
>>>
>>> Then the uwrmsr's unit will be { "uwrmsr", { { uwrmsr_Fixup, d_mode },
>> Rq }, 0 }.
>>> What‘s your opinion?
>>
>> Hmm, not very nice, but I can't exclude it simply won't get any better.
>> My desire was for there to not be any new fixup function, and for
>> OP_Skip_MODRM to be used directly in the table entry. (In any event, if you
>> really need to keep this new function, please combine the three if()-s into a
>> single one, helping readability quite a bit.
>>
>
> I have another idea, can I have a new function like
>
> OP_back_codep(...)
> {
> Ins->codep--;
> Return true;
> }
>
> So the uwrmsr's unit will be { "uwrmsr", { Skip_MODRM, Id, Back_Codep, Rq }, 0 }.
Well, the main thing I dislike is the decrementing of codep, no matter where
it's put. In case you don't think you can get away without, I guess I'll try
afterwards, aiming at an incremental change then.
Jan
next prev parent reply other threads:[~2023-10-24 12:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 7:24 Hu, Lin1
2023-10-16 12:11 ` Jan Beulich
2023-10-18 7:51 ` Hu, Lin1
2023-10-19 8:36 ` Jan Beulich
2023-10-24 8:38 ` Hu, Lin1
2023-10-24 8:55 ` Jan Beulich
2023-10-24 10:01 ` Hu, Lin1
2023-10-24 12:02 ` Jan Beulich [this message]
2023-10-25 2:01 ` Hu, Lin1
2023-10-25 8:48 ` Jan Beulich
2023-10-25 9:11 ` [PATCH][v3] " Hu, Lin1
2023-10-25 11:43 ` Jan Beulich
2023-10-26 6:14 ` Hu, Lin1
2023-10-26 6:21 ` [PATCH][v4] " Hu, Lin1
2023-10-26 8:31 ` Jan Beulich
2023-10-26 9:08 ` Hu, Lin1
2023-10-26 9:25 ` Jan Beulich
2023-10-26 10:26 ` Hu, Lin1
2023-10-27 9:00 ` [PATCH][v5] " Hu, Lin1
2023-10-27 13:36 ` Jan Beulich
2023-10-30 5:50 ` Hu, Lin1
2023-10-30 8:31 ` Jan Beulich
2023-10-31 1:43 ` Hu, Lin1
2023-10-31 2:14 ` [PATCH][v6] " Hu, Lin1
2023-10-31 8:03 ` Jan Beulich
2023-10-31 8:35 ` Hu, Lin1
2023-11-14 7:14 ` Jan Beulich
2023-11-15 3:09 ` Hu, Lin1
2023-11-15 3:34 ` Jiang, Haochen
2023-11-15 7:36 ` Jan Beulich
2023-11-15 7:41 ` Jiang, Haochen
2023-11-15 7:48 ` Jan Beulich
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=5c3a3d73-0f73-1941-ab31-6ad95050210e@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hongjiu.lu@intel.com \
--cc=lin1.hu@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).