From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7150C1EDA0F for ; Wed, 10 Dec 2025 14:22:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765376555; cv=none; b=HOuhBuZ3TFiZceM1eJmmNyeMKjivs5ZL9J+KqYbuP46UBsmKRHZyv2jAYjBZ8OZNj9Ox0+2nEmOAXL2P5HY2wT1s2uWAwVL9vZ2w1N0ja3ZsNicNQkY91Xehc32fa1shqgTI2ymu7jIHsPKLBeh4+hQ9p4zRiGjYRliVKkrjs6U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765376555; c=relaxed/simple; bh=ugCggwrq4wYFWVnyWDveG60bRr+Bcmb6i5/l8BMRFrY=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=pLrQsS9Vr4+nRIuGWOb5WdZNQ4c3dnvNNilTlQlpH5Ov1TuLzJUE4yvzU0cXfX8aXxEzg1z1VsIOz+WasnuBV9enM1eP9MI7W6mlIF2QLe2E6K86L+a5swzgrKbeccr/XAS9clfeFFFQpc8Tco/FyhuG9MiDaewKV4WsNv5uagI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com; spf=pass smtp.mailfrom=ventanamicro.com; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b=TljWbj5b; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ventanamicro.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ventanamicro.com header.i=@ventanamicro.com header.b="TljWbj5b" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-7e7a1b08e9dso307074b3a.2 for ; Wed, 10 Dec 2025 06:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1765376553; x=1765981353; darn=vger.kernel.org; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CCXWI9NMLIGKdShYILtPTYF4vSjxO5JfoEVGJGIlybo=; b=TljWbj5bE/wCGH3ObTj6ps9Tnv6qXgD3iBtI7lKZwLo51o+1mOERLPOrM5kOQgnyR7 wO1rrKGt9yLylKMKSs4Osqa6phBOF3g3MEtqz9niSVpfhpvTX23DKPdg+tjSgp020fmp 9AB34nIHZsIINw1DYxFR81ppyr1ORfmB1Uw8zXGrDHawXOT653l1B+/Z6Pttn3wWH7uc mMqUwfCWyFYm8U4/TEQRpxddKuueCKCRwBSpilpN7D713Uq/XdDYUhEoHbmCI3KVt08s shZWdyiBmBrG8vWO5dnM+pR9+BZ6w4/PsCnJ0TNad3vBTyq40EfzFnOLH6+gwor+LBe1 zCtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765376553; x=1765981353; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CCXWI9NMLIGKdShYILtPTYF4vSjxO5JfoEVGJGIlybo=; b=Tr66z2tffNGoCdkxulJtl8/WA3EGIP+OoZEeRBXM8W9zgNiRCy42CRWyUuYMqPOSBz lgqt0jY68atvbD8yXSXG+ZpLbVF3tsZThetpgG8thbqYGjztK6cd3IW4D0WoFA1DjGMB X11Mw5kHZnxFgNDqMGBf+WHIWAiqzhy0m/wAzd1KVNwcMPz6QEySXdMRQKkWKQFA2FLU tS0AA0LwbBACr7Z6UNDW0TczQ27ZLQ7PZDeVu5G+eZjmP0QcArtshgABNiD7qbh1Ap9M lYGLfeqFN8BoS2lrUOClHPviZy+WwNoCnWIPAJh7ogy7h2Rvey9IiW4DQ9dno0eM+NW8 LjoA== X-Forwarded-Encrypted: i=1; AJvYcCWAuvZEugyXciTfOEvbzufT01Rpyu2UA2E+4SqXQKp3uyJjbHrEvm12lDXo80+9y4dzS32gtma9tdvskYI=@vger.kernel.org X-Gm-Message-State: AOJu0YxJNFLKi0SBLPz0TQ/3SbEBrh20gy+FR3jOIdUvs2crrDPWjYJV RtWoOwZ6u0kplfBeRw2fUPI+ImPRe90g1vj/lfX0+cbAJz1+oWOfykSc+qHgc9lzfig= X-Gm-Gg: AY/fxX54Pe0Nrceie8aXodNp5B7rafRKiibsW6Basgx9lhWiunNyfvHdJEPqxkRUX+7 YZhkbI28vmDhjtVYoBSTOR4NiI+2wGBNzYWdKfqu82ZCqKbtPoPw5adRkEJXis1H/vhF/dUwGwQ oOEgbS4VumEksdh2B+XskWOe1m/2yPWqBHqWEEwrNH4m9w/aBlPqK6FHYLaqbEavWbDqp14m1rY 3zlojiWsb9j2KLSDri0DU3CKGwyenwk6IraVyedMVAd7y6+OQw1R+dOLZxiEeOElcNzlXMmesyN sP9EtEXdYbj3Frk+gddiB5Shmopc/ZQVKtEealCeu+89eRoAS+RoP63AnpUUdJmHs/B8hs6ncLd 1DAAmwK0tWbuSJPbnDnBU4eoD7MS7K8wHHKLpR/V8TAWr1uloq655Z6k4ezjPemQf3OCdeulh0J G3/ieR98DDr82orWE= X-Google-Smtp-Source: AGHT+IH+3VoOPNGdth2Gvi9WRF0RQbU1oEXZJauN9cdeoWV6+Oc4w9B7Ps/1EmONqCkTRg9MS367vA== X-Received: by 2002:a17:90b:1643:b0:343:6a63:85d1 with SMTP id 98e67ed59e1d1-34a728c81damr1938262a91.6.1765376552581; Wed, 10 Dec 2025 06:22:32 -0800 (PST) Received: from localhost ([2400:4050:300:5200:def6:5e63:b5ff:c77]) by smtp.gmail.com with UTF8SMTPSA id 98e67ed59e1d1-34a6ff012f1sm2743460a91.4.2025.12.10.06.22.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Dec 2025 06:22:31 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 10 Dec 2025 23:22:29 +0900 Message-Id: Subject: Re: [External] Re: [PATCH v3 5/8] riscv: smp: use NMI for CPU stop Cc: , , , , , , , , , , , , , , , , , , , , , , , , , "linux-riscv" To: "yunhui cui" From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= References: <20251127125305.89961-1-cuiyunhui@bytedance.com> <20251127125305.89961-6-cuiyunhui@bytedance.com> In-Reply-To: 2025-12-08T19:40:39+08:00, yunhui cui : > Hi Radim, > > On Thu, Dec 4, 2025 at 9:16=E2=80=AFPM Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> >> 2025-12-04T13:28:45+08:00, yunhui cui : >> > Hi Radim, >> > >> > On Thu, Dec 4, 2025 at 12:07=E2=80=AFPM Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> >> >> >> 2025-11-27T20:53:02+08:00, Yunhui Cui : >> >> > Use NMI instead of IPI for CPU stop if RISC-V SSE NMI is supported. >> >> > >> >> > Signed-off-by: Yunhui Cui >> >> > --- >> >> > diff --git a/drivers/firmware/riscv/riscv_sse_nmi.c b/drivers/firmw= are/riscv/riscv_sse_nmi.c >> >> > @@ -58,6 +58,7 @@ static int local_nmi_handler(u32 evt, void *arg, = struct pt_regs *regs) >> >> > type =3D atomic_read(this_cpu_ptr(&local_nmi)); >> >> > >> >> > NMI_HANDLE(LOCAL_NMI_CRASH, cpu_crash_stop, cpu, regs); >> >> > + NMI_HANDLE(LOCAL_NMI_STOP, cpu_stop); >> >> >> >> Please document the intended preemption design for all SSE events, >> >> because it will be a nightmare if we forget some assumptions in the >> >> coming years. (That includes the relative priorities of RAS/PMU/...) >> > >> > Actually, LOCAL_NMI_CRASH, LOCAL_NMI_STOP, LOCAL_NMI_BACKTRACE, >> > LOCAL_NMI_KGDB, ... are all implemented via the single SSE event >> > SBI_SSE_EVENT_LOCAL_SOFTWARE_INJECTED. Per the SSE design, no >> > preemption will occur among CRASH, STOP, BACKTRACE, and KGDB events. >> >> That is how it is. I don't understand why it must be like that. >> >> For example: PMU_OVERFLOW has lower event_id than SOFTWARE_INJECTED, so >> it will currently interrupt NMI_CRASH as they both have priority 0, >> although NMI_CRASH probably shouldn't be masked by anything, and should >> preempt everything. >> NMI_BACKTRACE, on the other hand, probably shouldn't have that high >> priority as there seem more important events (e.g. RAS and NMI_CRASH). >> >> The issues can be avoided by event priorities, masking, or deemed as >> non-issue, but I think it would be beneficial to provide some reasoning >> behind the design, as the choices don't seem obvious to me. > > Indeed, it is necessary to consider the priority among different > events. Should different priorities also be assigned to NMI_CRASH, > NMI_BACKTRACE, NMI_STOP, and NMI_KGDB? I think it would be beneficial to document the desired behavior even if we can't (currently?) implement it, because like you said, SSE can't directly express the priority when multiplexing SOFTWARE_INJECTED. > Do these operations need to be > visible to the BIOS? BIOS shouldn't care what lower privilege wants to do. SBI could define more events for software use, though. > Could you kindly provide some good suggestions? I think it would be good practice to explicitly set a unique priority when registering SSE events. Maybe through a global priority enum, and make sure that all event registrations are passing a value from that enum. That would make sure that different events interact like we expect them to, but it doesn't solve the multiplexing issue of SOFTWARE_INJECTED. If we're fine with all SOFTWARE_INJECTED sub-handlers having the maximal priority (higher than RAS/PMU/UNKNOWN_NMI/...), then we could hope that lower imporance handlers (e.g. BACKTRACE) won't hang, so the higher importance handlers (e.g. CRASH) would eventually run. We're dealing with low-occurrence scenarios, so this might be "good enough for now"... Situation would get simpler if we could avoid some sub-handlers; alternatively, it would get more complicated if SOFTWARE_INJECTED had lower priority than some other event -- we'd make CRASH partially recover its high priority image by masking other SSE events during its execution (and we'd need warding amulets against hangs and starvation). Thanks.