From: Daniel Axtens <dja@axtens.net>
To: Sandipan Das <sandipan@linux.ibm.com>, mpe@ellerman.id.au
Cc: naveen.n.rao@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
paulus@samba.org, ravi.bangoria@linux.ibm.com
Subject: Re: [RFC PATCH 3/5] powerpc: sstep: Add instruction emulation selftests
Date: Mon, 11 Feb 2019 11:47:44 +1100 [thread overview]
Message-ID: <87bm3j40cv.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <196d2330aef453b4eb3cb66febeb79110aadd567.1549253769.git.sandipan@linux.ibm.com>
Hi Sandipan,
I'm not really confident to review the asm, but I did have a couple of
questions about the C:
> +#define MAX_INSNS 32
This doesn't seem to be used...
> +int execute_instr(struct pt_regs *regs, unsigned int instr)
> +{
> + extern unsigned int exec_instr_execute[];
> + extern int exec_instr(struct pt_regs *regs);
These externs sit inside the function scope. This feels less than ideal
to me - is there a reason not to have these at global scope?
> +
> + if (!regs || !instr)
> + return -EINVAL;
> +
> + /* Patch the NOP with the actual instruction */
> + patch_instruction(&exec_instr_execute[0], instr);
> + if (exec_instr(regs)) {
> + pr_info("execution failed, opcode = 0x%08x\n", instr);
> + return -EFAULT;
> + }
> +
> + return 0;
> +}
> +late_initcall(run_sstep_tests);
A design question: is there a reason to run these as an initcall rather
than as a module that could either be built in or loaded separately? I'm
not saying you have to do this, but I was wondering if you had
considered it?
Lastly, snowpatch reports some checkpatch issues for this and your
remaining patches: https://patchwork.ozlabs.org/patch/1035683/ (You are
allowed to violate checkpatch rules with justification, FWIW)
Regards,
Daniel
> --
> 2.19.2
next prev parent reply other threads:[~2019-02-11 0:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-04 4:18 [RFC PATCH 0/5] powerpc: sstep: Emulation test infrastructure Sandipan Das
2019-02-04 4:18 ` [RFC PATCH 1/5] powerpc: Add bitmasks for D-form instruction fields Sandipan Das
2019-02-04 4:18 ` [RFC PATCH 2/5] powerpc: Add bitmask for Rc instruction field Sandipan Das
2019-02-04 4:18 ` [RFC PATCH 3/5] powerpc: sstep: Add instruction emulation selftests Sandipan Das
2019-02-11 0:47 ` Daniel Axtens [this message]
2019-02-11 10:15 ` Sandipan Das
2019-02-04 4:18 ` [RFC PATCH 4/5] powerpc: sstep: Add selftests for add[.] instruction Sandipan Das
2019-02-04 4:18 ` [RFC PATCH 5/5] powerpc: sstep: Add selftests for addc[.] instruction Sandipan Das
2019-02-11 1:00 ` Daniel Axtens
2019-02-11 10:14 ` Sandipan Das
2019-02-11 1:01 ` [RFC PATCH 0/5] powerpc: sstep: Emulation test infrastructure Daniel Axtens
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=87bm3j40cv.fsf@dja-thinkpad.axtens.net \
--to=dja@axtens.net \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.ibm.com \
--cc=paulus@samba.org \
--cc=ravi.bangoria@linux.ibm.com \
--cc=sandipan@linux.ibm.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 NNTP newsgroup(s).