Re: QEMU RAM allocation function fails

[Wayne Li <waynli329@gmail.com>]

The RAM region was just too big.  I made it smaller and the VM didn't
crash and moved past that point.

On Thu, Nov 5, 2020 at 1:58 PM Dr. David Alan Gilbert
<dgilbert@redhat.com> wrote:
>
> * Wayne Li (waynli329@gmail.com) wrote:
> > Dear QEMU list members,
> >
> > We developed a virtual machine that runs on QEMU.  This virtual
> > machine is pretty much an emulated P4080 processor with some
> > peripherals attached.  Initializing one of these peripherals, i.e. the
> > RAM, seems to be having problems.  I use the function
> > "memory_region_init_ram" to initialize the RAM and farther down the
> > call stack I see that the "qemu_ram_alloc" function returns an address
> > of 0 proving the RAM allocation wasn't successful.  Here is the block
> > of code in question copied from the file memory.c:
> >
> > void memory_region_init_ram_shared_nomigrate(MemoryRegion *mr,
> >                                              Object *owner,
> >                                              const char *name,
> >                                              uint64_t size,
> >                                              bool share,
> >                                              Error **errp)
> > {
> >     memory_region_init(mr, owner, name, size);
> >     mr->ram = true;
> >     mr->terminates = true;
> >     mr->destructor = memory_region_destructor_ram;
> >     mr->ram_block = qemu_ram_alloc(size, share, mr, errp);
> >     mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
> > }
> >
> > Tracing farther into the "qemu_ram_alloc" function reveals that the
> > function fails because inside the "qemu_ram_alloc_internal" function
> > in file exec.c, the function "ram_block_add" fails.  Interestingly, a
> > local_err object is populated here and the msg field in this object is
> > populated with the String "cannot set up guest memory 'ram0': Invalid
> > argument".  Here is the block of code in question copied from the file
> > exec.c:
>
> I'm surprised something didn't print that message out for you - most
> callers pass something like &error_fatal at the end and it should print
> it I think.
>
> >
> > RAMBlock *qemu_ram_alloc_internal(ram_addr_t size, ram_addr_t max_size,
> >                                   void (*resized)(const char*,
> >                                                   uint64_t length,
> >                                                   void *host),
> >                                   void *host, bool resizeable, bool share,
> >                                   MemoryRegion *mr, Error **errp)
> > {
> >     RAMBlock *new_block;
> >     Error *local_err = NULL;
> >
> >     size = HOST_PAGE_ALIGN(size);
> >     max_size = HOST_PAGE_ALIGN(max_size);
> >     new_block = g_malloc0(sizeof(*new_block));
> >     new_block->mr = mr;
> >     new_block->resized = resized;
> >     new_block->used_length = size;
> >     new_block->max_length = max_size;
> >     assert(max_size >= size);
> >     new_block->fd = -1;
> >     new_block->page_size = getpagesize();
> >     new_block->host = host;
> >     if (host) {
> >         new_block->flags |= RAM_PREALLOC;
> >     }
> >     if (resizeable) {
> >         new_block->flags |= RAM_RESIZEABLE;
> >     }
> >     ram_block_add(new_block, &local_err, share);
> >     if (local_err) {
> >         g_free(new_block);
> >         error_propagate(errp, local_err);
> >         return NULL;
> >     }
> >     return new_block;
> > }
> >
> > Anyway, our VM runs fine until it tries to access the RAM region so
> > this is a pretty critical problem for us to solve.  Does anyone know
> > much about these QEMU functions?  What could be causing these RAM
> > initialzation functions to fail in this way?
>
> You're going the right way - keep following it; that 'cannot set up
> guest memory' string is only in one place; softmmu/physmem.c - so
> the phys_mem_alloc must have failed.  That suggests either your
> max_length or your align requirements are wrong; but keep following
> it along.
>
> Dave
>
> > -Thanks, Wayne Li
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>