Hi Jonathan,
On 2/1/19 11:06 PM, Jonathan Behrens wrote:
> Public bug reported:
>
> I attempted to run qemu with a ram disk. However, when reading the
> contents of the disk from within the VM I only get back zeros.
>
> I was able to trace the issue to a mismatch of expectations on line 93
> of hw/riscv/virt.c. Specifically, when running in 32-bit mode the value
> of kernel_entry is sign extended to 64-bits, but load_image_targphys
> expects the start address to not be sign extended.
>
> Straw man patch (works for 32-bit but would probably break 64-bit VMs?):
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index e7f0716fb6..32216f993c 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -90,7 +90,7 @@ static hwaddr load_initrd(const char *filename, uint64_t
> mem_size,
> * halfway into RAM, and for boards with 256MB of RAM or more we put
> * the initrd at 128MB.
> */
> - *start = kernel_entry + MIN(mem_size / 2, 128 * MiB);
> + *start = (kernel_entry & 0xffffffff) + MIN(mem_size / 2, 128 * MiB);
>
> size = load_ramdisk(filename, *start, mem_size - *start);
> if (size == -1) {
>
>
> Run command:
>
> $ qemu/build/riscv32-softmmu/qemu-system-riscv32 -machine virt -kernel
> mykernel.elf -nographic -initrd payload
>
> Commit hash:
>
> 3a183e330dbd7dbcac3841737ac874979552cca2
>
> ** Affects: qemu
> Importance: Undecided
> Status: New
I believe this is fixed by the following patch:
"Ensure the kernel start address is correctly cast"
https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06358.html
Can you test it?
If if works you can reply to it with a
"Tested-by: Jonathan Behrens <your-email>"
to increases the odds it get merged ;)
Thanks,
Phil.
