From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 CC764257459 for ; Thu, 26 Mar 2026 16:45:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774543531; cv=none; b=D5ducN9SNYNFJrgQZLxKeioXVo+hoqo4FWWp4By2qTD+DuV3i6KzdNMVZi/sIH4PyuZKWPpxksa4e/vCGoWTTdGfT6/F79+ZZMq4g+h/jce9R7ZrnTR13XvNrt9cOzYSE/GQssLZVHTKRRzNv3eF37C1ZRDuFU/5DIGEoj7iGLQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774543531; c=relaxed/simple; bh=EV379XA4FUKXFVlAJBCkjUAR7vayrSReiUQ3Ml4I9Aw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=lJKp5CYv0b1hpIcmOtrdQdb9zqwatiLZ6EA1nCROudSvp1RCwFgacHNXcbGaORJxqMKuclRu4sHl7wCmKpXCgoyC+/A+Okr+PagoVyUHsVDutxEUegXljOqqhPwj+V4PoyucFOUX6HaMKqYpJTL4Pij93BL38qWDY2vty9sCfXM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=cwu8JR44; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=S+FXWy/s; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="cwu8JR44"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="S+FXWy/s" From: Nam Cao DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1774543525; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EV379XA4FUKXFVlAJBCkjUAR7vayrSReiUQ3Ml4I9Aw=; b=cwu8JR44+W5uNCWaXg80lD2goDd8tUpI6P7bCaBbjj/ZllXh4fOewsU5JcxjhvZB6qWu49 +w2jZiyqMMVYPYHafh3svZCQbjxhISK3goyTK6q4LgFDiWyupEiksf8AYpvSoSmvkW3ZMl ysXCiyrDPB6hot7gJBJwpVyld/yN7Tf26ZatQx3nlUlYhBMEeMd32xUyVY/4ztId+qndeu zD+1oFQ05EXKWQHizmspRV8lTOL77b83z2zX7OweEO3XpTZQQg2HPoS+ikRRroyRbnmH4H 3rHAn3O0ruFy7f5vtK0eIWHitO+SiMZ+Xx+700hJCsUVLOroEtkwsjkEAZX7Eg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1774543525; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EV379XA4FUKXFVlAJBCkjUAR7vayrSReiUQ3Ml4I9Aw=; b=S+FXWy/sflLzh9Npx7QiUw5ilCCH3uA+CfBHd3x0jHTyJtvs2KYFgH/Bld0A/GMsvLP9Qw P7r1rWEfyrRdr9Cg== To: Charles Mirabile Cc: alex@ghiti.fr, aou@eecs.berkeley.edu, haxel@fzi.de, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, palmer@dabbelt.com, pjw@kernel.org, vitaly.wool@konsulko.com, cmirabil@redhat.com Subject: Re: [PATCH] riscv: Remove support for XIP kernel In-Reply-To: <20260320160443.1850701-1-cmirabil@redhat.com> References: <20260202115403.2119218-1-namcao@linutronix.de> <20260320160443.1850701-1-cmirabil@redhat.com> Date: Thu, 26 Mar 2026 17:45:24 +0100 Message-ID: <87v7eiedzv.fsf@yellow.woof> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Charles Mirabile writes: > Chiming in as another voice interested in not scrapping XIP. I think > RISC-V is an interesting position as an ISA of being able to support > both desktop/server class high performance designs, but also low cost > embedded applications. The ability to run linux in M-Mode without an > MMU, and even XIP directly from storage within one code base just by > changing configuration options is fantastic and positions linux to be > the obvious kernel of choice for both kinds of RISC-V implementations. > > That being said, it is clear that these use-cases are not being tested > or maintained. The addition of runtime constant support for RISC-V also > broke no-mmu which I fixed in: > 8d90d9872edae ("riscv: fix runtime constant support for nommu kernels") > and clearly is also XIP which I did not test at the time and did not > realize. I have a patch to essentially just disable the runtime constants > logic on RISC-V when CONFIG_XIP_KERNEL is enabled here that should fix it: > https://lore.kernel.org/lkml/20260320155843.1848180-1-cmirabil@redhat.com FWIW, the patch looks correct to me. I can test it if we decided to keep XIP. > That being said, In truth I have not actually built or used an XIP linux > kernel on RISC-V, so I am not sure I can volunteer to test or maintain it > at this moment, but I am planning on experimenting with M-Mode noMMU XIP > linux on the sifive hifive unleashed board with the hope of creating a > kernel that can act as a linuxboot payload and essentially replace the > firmware of the device. With the fix I proposed, perhaps it is tenable to > not remove XIP at this time and go back to the status quo? I understand > that it is just kicking the can down the road until the next time someone > makes a change that breaks XIP and no one notices if no one is testing, > but maybe we can have a conversation about how we could improve the > situation in the meantime and have an actual plan to catch that before > such a breaking patch makes it to mainline next time. I'm not sure if we should be keeping it for the hope that maybe a use case will appear in the future. We can always revert it back when we do need it in the future. But for now, it is being maintenance burden with no benefit. I presume your experiment does not require the latest kernel, and you can use the older versions which still support XIP? Nam