Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp174130ybl; Tue, 13 Aug 2019 18:19:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqwfkJwFF6h06ktuKLbFqToHIw05SGvzsrT/DR480XuPLDUScvA5DrDe+cMssgK55SwqDvW0 X-Received: by 2002:a63:7d49:: with SMTP id m9mr37926481pgn.161.1565745574465; Tue, 13 Aug 2019 18:19:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565745574; cv=none; d=google.com; s=arc-20160816; b=naMYeTWFmO2puvYNtIyWHa/Bp8Jn3feVPQWeQfQsgZaqidfjymZuOXl8iJ9YYHOC9S VbVtumwdyK1E7VKtHkDMRBX+UnXoANPnTKKQzePWCOidzhfb4JkLfvbu0ruLOHWcWIVt v20cBNhLOKMCbWLTXCKS/NWX1vpr0gv2ua4a2gwV4tBFHw+qhWt43FnzYwMjbGZ/WDNj 1Xbb4p9aYvKky6UZSI0AzSwIo+kQsc1LmsOJhbIMnuvO1knMhI6ejuVp3FczkJJLtFpB Soz6D1SdIt+4Ft5/w4bFvyWPzHNMoY8RCAmUCou7+Xep9aJ3+gUcczaymyyksR4IdKcd peyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=w50UtoxxxguPj0Qzsc2vvVv8zgNNFP9/XFmO41TGs6o=; b=sPwZZ5R/jiDMq3Rd60Cq1RoORRD2jTTGeaer6qCzqbMxRffSpruuzqKO/h9+N13GAg gmxCHy5BZt24PymUCO0zUvbdaPA10re0eVqg7O5jrOysl1NmeICLD28ERWMDt3i5lUr2 TRnG56kmE1AqUuL0tnNgrg/+ZpaWwTz89m8F4pu7bo7GGXe8fx4dpiffNP3GAIFDSowx xG2m2skw/GpyU+9aL6Aevcy8cFFhj7zKL6a93Jm2jLi1MvPilMt+8ZDyabSpNd8rvbSk JgdGw3BEcUEoVcsvyAIn42dRZg+r45zkg4Uqf8gj/kFQpPtE2Ft8T1b9h7TY5Rfkla8L /amA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t185si63266386pgd.596.2019.08.13.18.19.16; Tue, 13 Aug 2019 18:19:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726851AbfHNBS3 (ORCPT + 99 others); Tue, 13 Aug 2019 21:18:29 -0400 Received: from 59-120-53-16.HINET-IP.hinet.net ([59.120.53.16]:27000 "EHLO ATCSQR.andestech.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726102AbfHNBS3 (ORCPT ); Tue, 13 Aug 2019 21:18:29 -0400 Received: from ATCSQR.andestech.com (localhost [127.0.0.2] (may be forged)) by ATCSQR.andestech.com with ESMTP id x7E0n9Jj017975 for ; Wed, 14 Aug 2019 08:49:09 +0800 (GMT-8) (envelope-from alankao@andestech.com) Received: from mail.andestech.com (atcpcs16.andestech.com [10.0.1.222]) by ATCSQR.andestech.com with ESMTP id x7E0mjaZ017904; Wed, 14 Aug 2019 08:48:45 +0800 (GMT-8) (envelope-from alankao@andestech.com) Received: from andestech.com (10.0.15.65) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.123.3; Wed, 14 Aug 2019 09:00:13 +0800 Date: Wed, 14 Aug 2019 09:00:14 +0800 From: Alan Kao To: Christoph Hellwig CC: Palmer Dabbelt , Paul Walmsley , Damien Le Moal , , Subject: Re: [PATCH 13/15] riscv: clear the instruction cache and all registers when booting Message-ID: <20190814010013.GA18655@andestech.com> References: <20190813154747.24256-1-hch@lst.de> <20190813154747.24256-14-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20190813154747.24256-14-hch@lst.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.0.15.65] X-DNSRBL: X-MAIL: ATCSQR.andestech.com x7E0mjaZ017904 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christoph, On Tue, Aug 13, 2019 at 05:47:45PM +0200, Christoph Hellwig wrote: > When we get booted we want a clear slate without any leaks from previous > supervisors or the firmware. Flush the instruction cache and then clear > all registers to known good values. This is really important for the > upcoming nommu support that runs on M-mode, but can't really harm when > running in S-mode either. Sure. > +#ifdef CONFIG_FPU But it doesn't really mean that the running system has an FPU given CONFIG_FPU enabled. Normally the existence of an FPU is checked in riscv_fill_hwcap by searching device tree, where the code looks like bool has_fpu = false; // this one is global ... #ifdef CONFIG_FPU if (elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D)) has_fpu = true; #endif Or does CONFIG_FPU have a more intuitive meaning when CONFIG_M_MODE is enabled? > + csrr t0, CSR_MISA > + andi t0, t0, (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D) > + bnez t0, .Lreset_regs_done > + > + li t1, SR_FS > + csrs CSR_XSTATUS, t1 > + fmv.s.x f0, zero > + fmv.s.x f1, zero > + fmv.s.x f2, zero > + fmv.s.x f3, zero > + fmv.s.x f4, zero > + fmv.s.x f5, zero > + fmv.s.x f6, zero > + fmv.s.x f7, zero > + fmv.s.x f8, zero > + fmv.s.x f9, zero > + fmv.s.x f10, zero > + fmv.s.x f11, zero > + fmv.s.x f12, zero > + fmv.s.x f13, zero > + fmv.s.x f14, zero > + fmv.s.x f15, zero > + fmv.s.x f16, zero > + fmv.s.x f17, zero > + fmv.s.x f18, zero > + fmv.s.x f19, zero > + fmv.s.x f20, zero > + fmv.s.x f21, zero > + fmv.s.x f22, zero > + fmv.s.x f23, zero > + fmv.s.x f24, zero > + fmv.s.x f25, zero > + fmv.s.x f26, zero > + fmv.s.x f27, zero > + fmv.s.x f28, zero > + fmv.s.x f29, zero > + fmv.s.x f30, zero > + fmv.s.x f31, zero > + csrw fcsr, 0 > + /* note that the caller must clear SR_FS */ > +#endif /* CONFIG_FPU */