On 20.08.21 18:00, Philippe Mathieu-Daudé wrote:
On 8/20/21 5:53 PM, David Hildenbrand wrote:
On 20.08.21 17:52, Philippe Mathieu-Daudé wrote:
When Linux refuses to overcommit a seriously wild allocation we get:
$ qemu-system-i386 -m 40000000
qemu-system-i386: cannot set up guest memory 'pc.ram': Cannot
allocate memory
Slighly improve the error message, displaying the memory size
requested (in case the user didn't expect unspecified memory size
unit is in MiB):
$ qemu-system-i386 -m 40000000
qemu-system-i386: Cannot set up 38.1 TiB of guest memory 'pc.ram':
Cannot allocate memory
Reported-by: Bin Meng <bmeng...@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com>
---
softmmu/physmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/softmmu/physmem.c b/softmmu/physmem.c
index 2e18947598e..2f300a9e79b 100644
--- a/softmmu/physmem.c
+++ b/softmmu/physmem.c
@@ -1982,8 +1982,10 @@ static void ram_block_add(RAMBlock *new_block,
Error **errp)
&new_block->mr->align,
shared, noreserve);
if (!new_block->host) {
+ g_autofree char *size_s =
size_to_str(new_block->max_length);
error_setg_errno(errp, errno,
- "cannot set up guest memory '%s'",
+ "Cannot set up %s of guest memory
'%s'",
+ size_s,
memory_region_name(new_block->mr));
qemu_mutex_unlock_ramlist();
return;
IIRC, ram blocks might not necessarily be used for guest memory ... or
is my memory wrong?
No clue, this error message was already here.
No problem to change s/guest/block/ although.
We should probably just adjust that as well (separate patch) ... but
your patch subject also mentions "guest memory".
Not opposed to printing the size, although I doubt that it will really
stop similar questions/problems getting raised.
--
Thanks,
David / dhildenb
