Re: Hart isolation configuration failure (error -3) with OpenSBI 1.8 on QEMU 10.1.3 rva22s64/rva23s64 profiles

[Thomas Perrot <thomas.perrot@bootlin.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3543 bytes --]

Hello,

On Thu, 2026-01-08 at 20:34 +0530, Anup Patel wrote:
> On Thu, Jan 8, 2026 at 7:12 PM Daniel Henrique Barboza
> <daniel.barboza@oss.qualcomm.com> wrote:
> > 
> > 
> > 
> > On 1/8/2026 10:33 AM, Anup Patel wrote:
> > > Hi Thomas,
> > > 
> > > On Wed, Jan 7, 2026 at 3:02 PM Thomas Perrot
> > > <thomas.perrot@bootlin.com> wrote:
> > > > 
> > > > Hello Xiang,
> > > > 
> > > > On Wed, 2026-01-07 at 10:48 +0800, Xiang W wrote:
> > > > > 在 2026-01-05一的 18:42 +0100，Thomas Perrot写道：
> > > > > > Hello,
> > > > > > 
> > > > > > Happy New Year!
> > > > > > 
> > > > > > I'm facing a hart isolation configuration error when
> > > > > > running
> > > > > > OpenSBI
> > > > > > 1.8 on QEMU 10.1.3 with the RISC-V application profiles
> > > > > > rva22s64
> > > > > > and
> > > > > > rva23s64:
> > > > > > 
> > > > > >      init_coldboot: hart isolation configure failed (error
> > > > > > -3)
> > > > > > 
> > > > > > No issue occurs when using the rv64 profile. The system
> > > > > > continues
> > > > > > to
> > > > > > boot after the error, but I'd like to understand the root
> > > > > > cause.
> > > > > > 
> > > > > > I haven't tested OpenSBI 1.8 on real hardware yet - that's
> > > > > > my next
> > > > > > step.
> > > > > > 
> > > > > > Is there a known QEMU issue? Is there a recommended
> > > > > > workaround
> > > > > > besides
> > > > > > using rv64?
> > > > > > 
> > > > > > Below is the complete trace:
> > > > > > 
> > > > > > qemu-system-riscv64 -device virtio-net-
> > > > > > device,netdev=net0,mac=52:54:00:12:35:02 -netdev
> > > > > > user,id=net0,hostfwd=tcp:127.0.0.1:2222-
> > > > > > :22,hostfwd=tcp:127.0.0.1:2323-
> > > > > > :23,tftp=/src/build/tmp/deploy/images/qemuriscv64 -object
> > > > > > rng-
> > > > > > random,filename=/dev/urandom,id=rng0 -device virtio-rng-
> > > > > > pci,rng=rng0 -
> > > > > > drive
> > > > > > id=disk0,file=/src/build/tmp/deploy/images/qemuriscv64/core
> > > > > > -
> > > > > > image-minimal-qemuriscv64.rootfs-
> > > > > > 20260105173847.ext4,if=none,format=raw
> > > > > > -device virtio-blk-device,drive=disk0 -device qemu-xhci -
> > > > > > device
> > > > > > usb-
> > > > > > tablet -device usb-kbd  -machine virt -cpu rva23s64 -smp 4
> > > > > > -m 256 -
> > > > > QEMU disables PMP by default; the following option needs to
> > > > > be added.
> > > > > 
> > > > > -cpu rva23s64,pmp=true
> > > > > 
> > > > 
> > > > Thank you. With the additional option, the issue no longer
> > > > occurs.
> > > 
> > > I have done an incremental OpenSBI v1.8.1 release
> > > to address this issue. With this incremental release,
> > > you don't have to explicitly pass "pmp=true" to
> > > rva22s64 and rva23s64 CPU types in QEMU.
> > 
> > Seems like we don't need this patch I sent a few days ago then:
> > 
> > 
> > "[PATCH] target/riscv/cpu.c: enable PMP by default for profile
> > CPUs"
> > 
> > https://lore.kernel.org/qemu-devel/20260106205152.3654975-1-daniel.barboza@oss.qualcomm.com/
> > 
> > 
> > We can leave this patch alone. We can also leave the update to
> > OpenSBI
> > 1.8 alone as well and update to 1.8.1 to get the fix.
> 
> I think the QEMU patch is still needed because without PMP
> there is nothing to protect M-mode firmware (OpenSBI) from
> lower privilege modes.
> 

Thank you for the update.

Kind regards,
Thomas Perrot

> Regards,
> Anup

-- 
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[-- Attachment #2: Type: text/plain, Size: 105 bytes --]

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi