From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3D86C433DF for ; Fri, 14 Aug 2020 09:44:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8B2AB20781 for ; Fri, 14 Aug 2020 09:44:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726890AbgHNJob convert rfc822-to-8bit (ORCPT ); Fri, 14 Aug 2020 05:44:31 -0400 Received: from mail-il1-f193.google.com ([209.85.166.193]:46994 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726889AbgHNJob (ORCPT ); Fri, 14 Aug 2020 05:44:31 -0400 Received: by mail-il1-f193.google.com with SMTP id c6so7882433ilo.13 for ; Fri, 14 Aug 2020 02:44:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xosEYrDoba41qWFRog+Uv/Mk1S2eoK9q+2rQ9FX5pWo=; b=hvxa6Xc+5yB9ItzLXbQghvGGUSoRzSKdfnkYV8PZlCdW+XsoJyCnbWVEFw9oRubIv2 Ex9fbhXOky5WguiwoK1GD0P5fh/7zwHsKLloP3n39PxaBPZyggZ/1ccQjry2KZiH4VAx f0m/gokzKjMBUZgtSdeSOoSCNjcwmJNW2SGs+NP2oZsbKdhyg2seJKcqRSOg4iyxIIw0 2H5wCEvzK1rDwvxjx7QsQH5iCvhwdTZc6XesB0MaHw2b9Td24TtMu2G39W0NNAnZkN0G 3iyKwXsozD91dAWWFKaHzaNKVQgZi5TXgld4FIttPGZQHDY5YM4f4ZxWOyFc6pm23G/O 40Dg== X-Gm-Message-State: AOAM532Ni6A2sl4Z5gbKQpj+qkaI+wwE/uQiy2QIAQZjJ+3JG4FbdR3L 5BD4eZB2tVymKU8ExLcIed8+3zrLjkRbHZ8KUAE= X-Google-Smtp-Source: ABdhPJzh3ixmp+5lff425K1TXESM9QgonCLgEq0zYMEhmo9YQsyqvfMhMAUNGIaJJTtsUWxORw+imYZDMtqOyh1zbhg= X-Received: by 2002:a05:6e02:962:: with SMTP id q2mr1860882ilt.171.1597398270011; Fri, 14 Aug 2020 02:44:30 -0700 (PDT) MIME-Version: 1.0 References: <20200805121021.GA12598@alpha.franken.de> <1c3cb503-720f-059e-2bac-ae692203c389@flygoat.com> <20200807131357.GA11979@alpha.franken.de> <410cf75c-4cf5-94d8-fbc9-821d38f8a299@flygoat.com> <96dbe0be-7af6-b182-bbe0-534883539812@flygoat.com> <20200810141219.GA2844@alpha.franken.de> <106e65f5-d456-deaa-b47b-45b2a461b048@flygoat.com> <20200811120645.GA6199@alpha.franken.de> In-Reply-To: <20200811120645.GA6199@alpha.franken.de> From: Huacai Chen Date: Fri, 14 Aug 2020 17:44:18 +0800 Message-ID: Subject: Re: [PATCH V3 1/2] MIPS: Loongson-3: Enable COP2 usage in kernel To: Thomas Bogendoerfer Cc: Jiaxun Yang , "open list:MIPS" , Fuxin Zhang , Zhangjin Wu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org Hi, Thomas, On Tue, Aug 11, 2020 at 8:08 PM Thomas Bogendoerfer wrote: > > On Tue, Aug 11, 2020 at 02:45:05PM +0800, Huacai Chen wrote: > > Hi, Thomas and Jiaxun, > > > > On Tue, Aug 11, 2020 at 10:18 AM Jiaxun Yang wrote: > > > > > > > > > > > > 在 2020/8/10 22:12, Thomas Bogendoerfer 写道: > > > > On Sun, Aug 09, 2020 at 10:53:13PM +0800, Jiaxun Yang wrote: > > > >> Thus we still need to enable CU2 with exception for user space, and we can > > > >> always enable CU2 in > > > >> kernel since kernel won't be compiled with hard-float. :-) > > > > I see, how about the patch below > > > That looks fine for me. > > > Is it good with you, Huacai? > > > > There are two problems: > > 1, zboot (arch/mips/boot/compressed/head.S) should be considered, > > because the initial value of Status may or may not contain CU2. > > 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. > > > 2, r4k_switch.S should set CU2 for the new process, otherwise it > > cannot use gslq/gssq while it in kernel (Because the new process > > doesn't contain CU2 in THERAD_STATUS. > > 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. Huacai > > Though a process sets CU2 when it enters kernel, but it > > only sets CU2 in hardware, not in THREAD_STATUS). > > A kernel thread will get THREAD_STATUS from current running kernel code, > at least that's how I read this code: > > if (unlikely(p->flags & PF_KTHREAD)) { > /* kernel thread */ > unsigned long status = p->thread.cp0_status; > memset(childregs, 0, sizeof(struct pt_regs)); > ti->addr_limit = KERNEL_DS; > p->thread.reg16 = usp; /* fn */ > p->thread.reg17 = kthread_arg; > p->thread.reg29 = childksp; > p->thread.reg31 = (unsigned long) ret_from_kernel_thread; > #if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX) > status = (status & ~(ST0_KUP | ST0_IEP | ST0_IEC)) | > ((status & (ST0_KUC | ST0_IEC)) << 2); > #else > status |= ST0_EXL; > #endif > childregs->cp0_status = status; > return 0; > } > > If there is still something missing, I want to find the root cause > and not paper over it in r4k_switch.S and IMHO break COP2 handling for > loongsoon completely. > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ]