From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Wayne Li <waynli329@gmail.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: QEMU RAM allocation function fails
Date: Thu, 5 Nov 2020 19:58:51 +0000 [thread overview]
Message-ID: <20201105195851.GC3187@work-vm> (raw)
In-Reply-To: <CAM2K0npECL3MpdkXH99htxGdTUTyC47PtnGAT4nkazpV6_rUPA@mail.gmail.com>
* 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
next prev parent reply other threads:[~2020-11-05 20:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-05 19:50 QEMU RAM allocation function fails Wayne Li
2020-11-05 19:58 ` Dr. David Alan Gilbert [this message]
2020-11-05 20:08 ` Wayne Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201105195851.GC3187@work-vm \
--to=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=waynli329@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).