[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <547FC530.1060109@caviumnetworks.com>
Date: Wed, 3 Dec 2014 18:21:36 -0800
From: David Daney <ddaney@...iumnetworks.com>
To: Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
CC: David Daney <ddaney.cavm@...il.com>, <linux-mips@...ux-mips.org>,
<ralf@...ux-mips.org>, <Zubair.Kakakhel@...tec.com>,
<geert+renesas@...der.be>, <peterz@...radead.org>,
<paul.gortmaker@...driver.com>, <macro@...ux-mips.org>,
<chenhc@...ote.com>, <cl@...ux.com>, <mingo@...nel.org>,
<richard@....at>, <zajec5@...il.com>, <james.hogan@...tec.com>,
<keescook@...omium.org>, <tj@...nel.org>, <alex@...x-smith.me.uk>,
<pbonzini@...hat.com>, <blogic@...nwrt.org>,
<paul.burton@...tec.com>, <qais.yousef@...tec.com>,
<linux-kernel@...r.kernel.org>, <markos.chandras@...tec.com>,
<dengcheng.zhu@...tec.com>, <manuel.lauss@...il.com>,
<lars.persson@...s.com>, David Daney <david.daney@...ium.com>
Subject: Re: [PATCH 2/3] MIPS: Add full ISA emulator.
On 12/03/2014 05:56 PM, Leonid Yegoshin wrote:
> David,
>
> I feel we can close a discission at that point - we disagree which
> approach is better, and there is no sense to continue dancing around.
>
That is something I do agree with.
> I see only two technical issues here which differs:
>
> 1. You believe your GCC experts, I trust HW Architecture manual and
> don't trust toolchain people too much ==> we see a different value in
> fact that your approach has a subset of emulated ISAs (and it can't, of
> course, emulate anything because some custom opcodes are reused).
Yes, I agree that the emulation approach cannot handle some of the cases
you mention (most would have to be the result of hand coded assembly
specifically trying to break it).
>
> 2. My approach is ready to use and is used right now, you still have a
> framework which passed an initial boot.
Let's add some more, please correct me if I misstate the facts:
3) Your approach uses one additional page of memory per user space
thread, even if emulation is never needed or there is a hardware FPU.
4) Your approach adds a Thread creation overhead of copy_page().
>
>
> On 12/03/2014 05:29 PM, David Daney wrote:
>> On 12/03/2014 04:52 PM, Leonid Yegoshin wrote:
>>> On 12/03/2014 04:20 PM, David Daney wrote:
>>>> It is a proof of concept. R6 can easily be added if needed.
>>>>
>>>> Your XOL emulation doesn't handle R6 either, so this is no worse than
>>>> your patch in that respect.
>>>
>>> You probably didn't research it well. A lot of changes in
>>> arch/mips/kernel/branch.c and and arch/mips/math-emu/cp1emu.c, all of it
>>> related with R6.
>>>
>>
>> I looked at:
>> commit 3a18ca061311f2f1ee9c44012f89c7436d392117
>>
>> And I saw no R6 support.
>>
>> Is it there, or in some other branch that isn't merged?
>
> Sorry, I misunderstood your statement:
>
> Yes, my "MIPS: Setup an instruction emulation in VDSO protected page
> instead of user stack <http://patchwork.linux-mips.org/patch/8631/>" has
> no any MIPS R6 specifics and actually has no any another MIPS Rx
> specific or FPU specific besides the fact that emulation can be done by
> multiple emulators and a small stack is supported in so-called "VDSO"
> page. I just remember that I pointed you to place where MIPS R6 is done
> and it has a lot of MIPS R6 instruction emulation and confused both events.
>
> - Leonid.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists