Okay, I need to classify this bug report into one of the given categories: mistranslation, assembly, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor. The bug is about the initrd not loading on RISC-V32. The user ran QEMU with a ram disk but only got zeros when accessing it from within the VM. They traced the issue to line 93 of hw/riscv/virt.c where there's a sign extension problem in kernel_entry for 32-bit mode. Looking at the code change they suggested, they modified *start by adding (kernel_entry & 0xffffffff), which suggests that kernel_entry was being treated as a signed value but needs to be unsigned. This indicates an issue with how addresses are handled when switching from 32-bit to 64-bit context, possibly related to how the hypervisor or machine handles the memory mappings. Since this is about loading the initrd and the problem lies in address handling during VM setup, it's likely a boot-related issue. The kernel_entry might be sign-extended incorrectly when passed to load_image_targphys, causing the initrd to be placed at an incorrect location or not loaded at all. Therefore, the category should be 'boot'. The bug relates to how the initial RAM disk (initrd) is loaded during the boot process of a RISC-V32 VM. The issue arises from improper handling of the kernel_entry address, which affects where the initrd is placed in memory. This points to an error occurring during the boot phase rather than other areas like networking or graphics. **boot**