Re: [Qemu-devel] [Bug 1814343] [NEW] Initrd not loaded on riscv32

[Alistair Francis <alistair23@gmail.com>]

On Fri, Feb 1, 2019 at 3:26 PM Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>
> 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 ;)

Did you get a chance to test this Jonathan?

Alistair

>
> Thanks,
>
> Phil.
>