From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Markos Chandras <markos.chandras@imgtec.com>
Cc: <linux-mips@linux-mips.org>, <paul.burton@imgtec.com>,
<david.daney@cavium.com>, <Steven.Hill@imgtec.com>,
<linux-kernel@vger.kernel.org>, <ralf@linux-mips.org>,
<macro@linux-mips.org>
Subject: Re: [PATCH] MIPS: R6: emulation of PC-relative instructions
Date: Tue, 11 Aug 2015 11:24:07 -0700 [thread overview]
Message-ID: <55CA3DC7.8080206@imgtec.com> (raw)
In-Reply-To: <20150811144101.GA25145@mchandras-linux.le.imgtec.org>
On 08/11/2015 07:41 AM, Markos Chandras wrote:
> Hi,
>
> On Wed, Aug 05, 2015 at 04:53:43PM -0700, Leonid Yegoshin wrote:
>> if (nir) {
>> err = mipsr6_emul(regs, nir);
>> if (err > 0) {
>> + regs->cp0_epc = nepc;
> Does this change belog to this patch? If so why?
Yes, it is needed for correct address calculation. Until PC-relative
instruction emulation it was not needed in dsemul().
> Maybe a comment would help?
> It does feel like it fixes a different problem but I haven't read your patch in depth.
>
>>
>>
>>
>> #include "ieee754.h"
>>
>> +#ifdef CONFIG_CPU_MIPSR6
> Can we simply avoid the if/def for R6 please? Just leave this function as is and
> use if(cpu_has_mips_r6) when calling it. If you can't do that, please explain
> why.
Yes, we can. But we have a bunch of that in many places and somewhere it
is difficult to avoid "#ifdef".
I just like to have an uniform standard.
Besides that "#ifdef" assures quickly that it is a build time choice but
not runtime.
>> +
>> +static int mipsr6_pc(struct pt_regs *regs, mips_instruction inst, unsigned long cpc,
>> + unsigned long bpc, unsigned long r31)
>> +{
>> + union mips_instruction ir = (union mips_instruction)inst;
>> + register unsigned long vaddr;
>> + unsigned int val;
>> + int err = SIGILL;
>> +
>> + if (ir.rel_format.opcode != pcrel_op)
>> + return SIGILL;
>> +
>> + switch (ir.rel_format.op) {
>> + case addiupc_op:
>> + vaddr = regs->cp0_epc + (ir.rel_format.simmediate << 2);
>> + if (config_enabled(CONFIG_64BIT) && !(regs->cp0_status & ST0_UX))
>> + __asm__ __volatile__("sll %0, %0, 0":"+&r"(vaddr)::);
>> + regs->regs[ir.rel_format.rs] = vaddr;
>> + return 0;
>> +#ifdef CONFIG_CPU_MIPS64
> Could you use cpu_has_mips64 and avoid the if/def
No we can't - cpu_has_mips64 is a CPU ISA feature but here is a kernel
code capability restriction. The difference happens during running
MIPS32 kernel on MIPS64 processor. We should not emulate MIPS64
instructions on MIPS32 kernel.
> and return SIGILL if it is not
> true?
The common return standard for emulation functions in MIPS is:
0 - OK, emulation done
SIGILL - doesn't recognize an instruction, it still may be some
another way to fix a problem or SIGILL.
other - some trouble or whatever (non-standardized, in MIPS R2
emulator it has subcodes)
I don't see a reason to change it and have here a special standard.
- Leonid.
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org, paul.burton@imgtec.com,
david.daney@cavium.com, Steven.Hill@imgtec.com,
linux-kernel@vger.kernel.org, ralf@linux-mips.org,
macro@linux-mips.org
Subject: Re: [PATCH] MIPS: R6: emulation of PC-relative instructions
Date: Tue, 11 Aug 2015 11:24:07 -0700 [thread overview]
Message-ID: <55CA3DC7.8080206@imgtec.com> (raw)
Message-ID: <20150811182407.v4cMRuOmJ4sO-XOZP36YCexU1Ahwfi1wLzt-R3Jw0mU@z> (raw)
In-Reply-To: <20150811144101.GA25145@mchandras-linux.le.imgtec.org>
On 08/11/2015 07:41 AM, Markos Chandras wrote:
> Hi,
>
> On Wed, Aug 05, 2015 at 04:53:43PM -0700, Leonid Yegoshin wrote:
>> if (nir) {
>> err = mipsr6_emul(regs, nir);
>> if (err > 0) {
>> + regs->cp0_epc = nepc;
> Does this change belog to this patch? If so why?
Yes, it is needed for correct address calculation. Until PC-relative
instruction emulation it was not needed in dsemul().
> Maybe a comment would help?
> It does feel like it fixes a different problem but I haven't read your patch in depth.
>
>>
>>
>>
>> #include "ieee754.h"
>>
>> +#ifdef CONFIG_CPU_MIPSR6
> Can we simply avoid the if/def for R6 please? Just leave this function as is and
> use if(cpu_has_mips_r6) when calling it. If you can't do that, please explain
> why.
Yes, we can. But we have a bunch of that in many places and somewhere it
is difficult to avoid "#ifdef".
I just like to have an uniform standard.
Besides that "#ifdef" assures quickly that it is a build time choice but
not runtime.
>> +
>> +static int mipsr6_pc(struct pt_regs *regs, mips_instruction inst, unsigned long cpc,
>> + unsigned long bpc, unsigned long r31)
>> +{
>> + union mips_instruction ir = (union mips_instruction)inst;
>> + register unsigned long vaddr;
>> + unsigned int val;
>> + int err = SIGILL;
>> +
>> + if (ir.rel_format.opcode != pcrel_op)
>> + return SIGILL;
>> +
>> + switch (ir.rel_format.op) {
>> + case addiupc_op:
>> + vaddr = regs->cp0_epc + (ir.rel_format.simmediate << 2);
>> + if (config_enabled(CONFIG_64BIT) && !(regs->cp0_status & ST0_UX))
>> + __asm__ __volatile__("sll %0, %0, 0":"+&r"(vaddr)::);
>> + regs->regs[ir.rel_format.rs] = vaddr;
>> + return 0;
>> +#ifdef CONFIG_CPU_MIPS64
> Could you use cpu_has_mips64 and avoid the if/def
No we can't - cpu_has_mips64 is a CPU ISA feature but here is a kernel
code capability restriction. The difference happens during running
MIPS32 kernel on MIPS64 processor. We should not emulate MIPS64
instructions on MIPS32 kernel.
> and return SIGILL if it is not
> true?
The common return standard for emulation functions in MIPS is:
0 - OK, emulation done
SIGILL - doesn't recognize an instruction, it still may be some
another way to fix a problem or SIGILL.
other - some trouble or whatever (non-standardized, in MIPS R2
emulator it has subcodes)
I don't see a reason to change it and have here a special standard.
- Leonid.
>
>
next prev parent reply other threads:[~2015-08-11 18:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-05 23:53 [PATCH] MIPS: R6: emulation of PC-relative instructions Leonid Yegoshin
2015-08-05 23:53 ` Leonid Yegoshin
2015-08-11 14:41 ` Markos Chandras
2015-08-11 14:41 ` Markos Chandras
2015-08-11 18:24 ` Leonid Yegoshin [this message]
2015-08-11 18:24 ` Leonid Yegoshin
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=55CA3DC7.8080206@imgtec.com \
--to=leonid.yegoshin@imgtec.com \
--cc=Steven.Hill@imgtec.com \
--cc=david.daney@cavium.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=macro@linux-mips.org \
--cc=markos.chandras@imgtec.com \
--cc=paul.burton@imgtec.com \
--cc=ralf@linux-mips.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.