[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QEMU RAM allocation function fails
From: |
Wayne Li |
Subject: |
Re: QEMU RAM allocation function fails |
Date: |
Thu, 5 Nov 2020 14:08:37 -0600 |
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
>