From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 256E42DC765 for ; Wed, 15 Apr 2026 12:38:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776256687; cv=none; b=W26nXB44j7HisLRCmDvOPI9CkbMPaynVNsFHLO73JFp41YfGpOO6q6lGe9OOMyM99QAp8yfH1+rXbDoEZUYCb4gljq+oEtLT97c0ryngx2w6hk0nVo3iddv0QdSKK+JPtShOsCWs8R1A/q7oHqBzUOqv9FzM5s0aQYa2rgiAevA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776256687; c=relaxed/simple; bh=rUXXql8OmvL63+SWbdYYSoqaYfAB+642IF5kvKG8Pic=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=llDkvyqYmnfRl2aD2ixWqQWFXgZb6UDhnUpv4JgUSgCx28XYP8yi5749Pqb7Z3WUDbYjSHwtTzzAub0mVFI3t3xTpu6zQDN2LzQ6OA2ZSpNO1Lnfw0GSyW/udpusW3dGqNq/5zAjsaQNFsq+TSgKy4k5FazvCySvIl0N1O6Ctdo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=riZ7J1RK; arc=none smtp.client-ip=115.124.30.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="riZ7J1RK" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776256682; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=IuRIdB05XOvFlg+W6dwU8jnLRNwetfEuTnQThR5If4M=; b=riZ7J1RK4qg14Q7cEBC0dR3/JrY0HWeAfeIe9cf1tUwbvvPJ47zWrUzEz5pAvGUO8dNfXat8yky1QOcfe4ecUI7TcWnjtRCKnfcYwczhOAzwFZfORM3TLvSv2oAUqw1CMu+tVLH9KhdTlb0MEIko9bAJNTIAEuqQ/RVgVIt6yTQ= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=cp0613@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0X14hhr6_1776256677; Received: from DESKTOP-S9E58SO.localdomain(mailfrom:cp0613@linux.alibaba.com fp:SMTPD_---0X14hhr6_1776256677 cluster:ay36) by smtp.aliyun-inc.com; Wed, 15 Apr 2026 20:38:01 +0800 From: Chen Pei To: wangruikang@iscas.ac.cn Cc: pjw@kernel.org, anup@brainfault.org, andrew.jones@oss.qualcomm.com, guoren@kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, opensbi@lists.infradead.org Subject: Re: [PATCH v2] riscv: smp: Align secondary_start_sbi to 4 bytes Date: Wed, 15 Apr 2026 20:37:57 +0800 Message-ID: <20260415123757.123581-1-cp0613@linux.alibaba.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <83397314-c7f3-4122-9587-80c29b1d13aa@iscas.ac.cn> References: <83397314-c7f3-4122-9587-80c29b1d13aa@iscas.ac.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, 15 Apr 2026 11:39:22 +0800, wangruikang@iscas.ac.cn wrote: > > During SMP boot, the secondary_start_sbi address is passed to the > > slave core via sbi_hsm_hart_start. In OpenSBI, this address is > > written to STVEC in sbi_hart_switch_mode. > > This is certainly odd (OpenSBI git blames to initial git commit. No idea > why this was needed.) but technically permitted by the SBI HSM spec (see > below). > > * Anup and other opensbi folks: Do you know/remember why it was there? > It's not really a bug, but some historical context would be appreciated. Yes, looking forward to responses from Anup and other opensbi folks. > > According to the privileged specification, the BASE field of STVEC > > must always be aligned on a 4-byte boundary. However, System.map > > reveals that secondary_start_sbi is not a 4-byte aligned address. > > > > For example, the address of secondary_start_sbi is > > 0xffffffff80001066, and the disassembly is as follows: > > > > Dump of assembler code from 0xffffffff80001052 to 0xffffffff8000107a: > > 0xffffffff80001052 <_start+4178>: c.nop -11 > > 0xffffffff80001054 <_start+4180>: auipc gp,0x1a1f > > 0xffffffff80001058 <_start+4184>: addi gp,gp,84 > > 0xffffffff8000105c <_start+4188>: csrw satp,a2 > > 0xffffffff80001060 <_start+4192>: sfence.vma > > 0xffffffff80001064 <_start+4196>: ret > > 0xffffffff80001066 <_start+4198>: csrw sie,zero > > 0xffffffff8000106a <_start+4202>: csrw sip,zero > > 0xffffffff8000106e <_start+4206>: li t0,2 > > 0xffffffff80001070 <_start+4208>: csrw scounteren,t0 > > 0xffffffff80001074 <_start+4212>: auipc gp,0x1a1f > > 0xffffffff80001078 <_start+4216>: addi gp,gp,52 > > > > When writing to STVEC at address 0xffffffff80001066, the actual > > write address is 0xffffffff80001064, corresponding to the address > > of the previous ret instruction. > Also technically permitted. Yes, but this is unintended behavior, and we should avoid it. > > This is unexpected, and if an > > interrupt occurs at this point, it will cause unpredictable results. > > > > However, secondary_start_sbi immediately masks all interrupts and > > updates STVEC, so no problems occurred. > > An interrupt cannot trap in between secondary_start_sbi starting and the > interrupts getting masked individually. The only arch state guaranteed > by HSM is [1]: > > |Register Name | Register Value > |satp | 0 > |sstatus.SIE | 0 > |a0 | hartid > |a1 | `opaque` parameter > |All other registers remain in an undefined state. > > Of which sstatus.SIE = 0 means that interrupts are masked in Supervisor > mode. > > In summary, it is more reasonable to make secondary_start_sbi > > satisfy 4-byte alignment. > > Thus, it is unnecessary. > > If this fixes a bug where an interrupt can trap into the wrong stvec for > you, then your firmware is broken. This isn't about fixing a bug (as mentioned earlier, it's highly unlikely to happen), but rather the STVEC check mechanism added to QEMU discovered this issue. Regarding the problem itself, I would appreciate any clarification or modifications from OpenSBI, but currently this modification is the simplest and most feasible. > Michael's suggestion about SYM_CODE_START still stands, but if you do > that, that's just a really minor refactoring, and in any case the > current commit message cannot stand. > > Vivian "dramforever" Wang > > [1]: > https://github.com/riscv-non-isa/riscv-sbi-doc/blob/v3.0/src/ext-hsm.adoc#function-hart-start-fid-0 Thanks, Pei