From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Huacai Chen <chenhc@lemote.com>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>,
"open list:MIPS" <linux-mips@vger.kernel.org>,
Fuxin Zhang <zhangfx@lemote.com>,
Zhangjin Wu <wuzhangjin@gmail.com>
Subject: Re: [PATCH V3 1/2] MIPS: Loongson-3: Enable COP2 usage in kernel
Date: Fri, 28 Aug 2020 10:42:43 +0200 [thread overview]
Message-ID: <20200828084242.GA6817@alpha.franken.de> (raw)
In-Reply-To: <CAAhV-H41-nyVPy1weKT_10A9_ATYB0pYq0_1jMm3Z3adv0Yutw@mail.gmail.com>
On Thu, Aug 27, 2020 at 11:48:29AM +0800, Huacai Chen wrote:
> Hi, Thomas,
>
> On Wed, Aug 26, 2020 at 8:48 PM Thomas Bogendoerfer
> <tsbogend@alpha.franken.de> wrote:
> >
> > On Fri, Aug 14, 2020 at 05:44:18PM +0800, Huacai Chen wrote:
> > > On Tue, Aug 11, 2020 at 8:08 PM Thomas Bogendoerfer
> > > <tsbogend@alpha.franken.de> wrote:
> > > > this comes with it's own memcpy/memset and stuff, I don't see a reason why
> > > > COP2 needs to be enabled there,
> > > gslq/gssq can also be generated by toolchains.
> >
> > I don't want to introduce every single CPU optimization bits into such
> > a closed first stage loader. So please use $(filter-out) in
> > arch/mips/boot/compressed/Makefile to disable creation of 16byte load/stores.
> >
> > > > which is correct for all user space process, otherwise the whole
> > > > cop2 exception thing wouldn't work. And if cop2 exception handling
> > > > has been run it's set in THREAD_STATUS.
> > > >
> > > THREAD_STATUS means thread_struct.cp0_status, which is the cp0_status
> > > when a process runs in kernel-space. KSTK_STATUS (what you have seen
> > > in copy_thread_tls() below) means cp0_status in a process's kernel
> > > stack, which saves the cp0_status when a process runs in user-space.
> > > Whether COP2 exception can work depends on that KSTK_STATUS (but not
> > > THREAD_STATUS) should not contain CU2 at the first time. So, whether
> > > or not THREAD_STATUS contains CU2, it won't break COP2 handling.
> >
> > so why don't we fix the the in-kernel cp0_status instead ?
> >
> > How about this ?
> >
> > diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
> > index 90b869297893..26fb77a8d406 100644
> > --- a/arch/mips/kernel/process.c
> > +++ b/arch/mips/kernel/process.c
> > @@ -133,6 +133,7 @@ int copy_thread_tls(unsigned long clone_flags, unsigned long usp,
> > /* Put the stack after the struct pt_regs. */
> > childksp = (unsigned long) childregs;
> > p->thread.cp0_status = read_c0_status() & ~(ST0_CU2|ST0_CU1);
> > + p->thread.cp0_status |= ST0_KERNEL_CUMASK;
> > if (unlikely(p->flags & PF_KTHREAD)) {
> > /* kernel thread */
> > unsigned long status = p->thread.cp0_status;
> This seems a good idea, I will send a new version.
IMHO it migt be even better to just use
p->thread.cp0_status = read_c0_status();
without masking. We are in kernel, so we took care of whatever CU1/CU2
handling had to be done at kernel entry. So keeping the current cp0 status
for the new thread looks more sane to me.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
next prev parent reply other threads:[~2020-08-28 8:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-02 4:55 [PATCH V3 1/2] MIPS: Loongson-3: Enable COP2 usage in kernel Huacai Chen
2020-05-02 4:55 ` [PATCH V3 2/2] MIPS: Loongson-3: Calculate ra properly when unwinding the stack Huacai Chen
2020-05-06 5:29 ` [PATCH V3 1/2] MIPS: Loongson-3: Enable COP2 usage in kernel Jiaxun Yang
2020-08-01 7:59 ` Huacai Chen
2020-08-05 12:10 ` Thomas Bogendoerfer
2020-08-05 13:51 ` Jiaxun Yang
2020-08-06 1:15 ` Huacai Chen
2020-08-07 13:13 ` Thomas Bogendoerfer
2020-08-07 13:25 ` Jiaxun Yang
2020-08-07 13:36 ` Thomas Bogendoerfer
2020-08-09 14:53 ` Jiaxun Yang
2020-08-10 14:12 ` Thomas Bogendoerfer
2020-08-11 2:16 ` Jiaxun Yang
2020-08-11 6:45 ` Huacai Chen
2020-08-11 12:06 ` Thomas Bogendoerfer
2020-08-14 9:44 ` Huacai Chen
2020-08-14 13:16 ` Jiaxun Yang
2020-08-26 12:46 ` Thomas Bogendoerfer
2020-08-27 3:48 ` Huacai Chen
2020-08-28 8:42 ` Thomas Bogendoerfer [this message]
2020-08-28 9:21 ` Huacai Chen
2020-08-28 9:33 ` Thomas Bogendoerfer
2020-08-28 9:52 ` Huacai Chen
2020-08-28 11:12 ` Thomas Bogendoerfer
2020-09-02 6:54 ` Huacai Chen
2020-09-03 8:43 ` Thomas Bogendoerfer
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=20200828084242.GA6817@alpha.franken.de \
--to=tsbogend@alpha.franken.de \
--cc=chenhc@lemote.com \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-mips@vger.kernel.org \
--cc=wuzhangjin@gmail.com \
--cc=zhangfx@lemote.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 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.