Sorry for the late follow-up Answering directly since it's still an open question: the bug was found by actually booting a >=2GiB pflash image against -M niagara and hitting the exact symptom described: exit(1) before the CPU ever ran, no OpenBoot output at all. Tracing that to blk_getlength() returning int64_t while niagara_init() stored it in a plain int came after, as the explanation for what was observed, not before.
It helped advance the investigation into the bootability of the current sun4v images, especially for Solaris 10 DVD, bigger than 2GiB - several of those failed for exactly this reason before the fix. Regards Dmitry. On Tue, Jul 14, 2026 at 11:46 PM Mark Cave-Ayland < [email protected]> wrote: > On 10/07/2026 23:23, Dmitry Pimenov wrote: > > > blk_getlength() returns int64_t, but niagara_init() stored it in an int, > > truncating the if=pflash virtual-ramdisk size for images >= 2 GiB. A ~4 > GiB > > image truncated to 0/negative, failed the `size > 0` check, and exit(1)'d > > before the CPU ran, ending with: > > > > qemu-system-sparc64: could not load ram disk > > > > AI-used-for: code (bug fix) > > Signed-off-by: Dmitry Pimenov <[email protected]> > > --- > > hw/sparc64/niagara.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/sparc64/niagara.c b/hw/sparc64/niagara.c > > index 1211ecb82d..ad5e5945a8 100644 > > --- a/hw/sparc64/niagara.c > > +++ b/hw/sparc64/niagara.c > > @@ -137,7 +137,7 @@ static void niagara_init(MachineState *machine) > > outside of the partition RAM */ > > if (dinfo) { > > BlockBackend *blk = blk_by_legacy_dinfo(dinfo); > > - int size = blk_getlength(blk); > > + int64_t size = blk_getlength(blk); > > if (size > 0) { > > memory_region_init_ram(&s->vdisk_ram, NULL, > "sun4v_vdisk.ram", size, > > &error_fatal); > > -- > > 2.43.0 > > Oh, curious - is this a static/AI analysis find, or are you actively using > the sun4v > emulation? Anyhow: > > Acked-by: Mark Cave-Ayland <[email protected]> > > > ATB, > > Mark. > >
