From: "Andreas Färber" <afaerber@suse.de>
To: Markus Armbruster <armbru@redhat.com>
Cc: peter.maydell@linaro.org, stefano.stabellini@eu.citrix.com,
mtosatti@redhat.com, qemu-devel@nongnu.org, agraf@suse.de,
borntraeger@de.ibm.com, mkletzan@redhat.com, pbonzini@redhat.com,
rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v3 for 1.6 7/8] exec: Don't abort when we can't allocate guest memory
Date: Wed, 31 Jul 2013 15:51:08 +0200 [thread overview]
Message-ID: <51F9164C.8070205@suse.de> (raw)
In-Reply-To: <1375276272-15988-8-git-send-email-armbru@redhat.com>
Am 31.07.2013 15:11, schrieb Markus Armbruster:
> We abort() on memory allocation failure. abort() is appropriate for
> programming errors. Maybe most memory allocation failures are
> programming errors, maybe not. But guest memory allocation failure
> isn't, and aborting when the user asks for more memory than we can
> provide is not nice. exit(1) instead, and do it in just one place, so
> the error message is consistent.
>
> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
> exec.c | 5 +++++
> target-s390x/kvm.c | 6 +-----
> util/oslib-posix.c | 4 +---
> util/oslib-win32.c | 5 +----
> 4 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index 231d04e..0cfca3a 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1162,6 +1162,11 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
> }
> if (!new_block->host) {
> new_block->host = phys_mem_alloc(size);
> + if (!new_block->host) {
> + fprintf(stderr, "Cannot set up guest memory '%s': %s\n",
> + new_block->mr->name, strerror(errno));
This could use error_report() while at it, but still
Reviewed-by: Andreas Färber <afaerber@suse.de>
Thought I had ack'ed it long ago, but I guess something minor changed.
Cheers,
Andreas
> + exit(1);
> + }
> memory_try_enable_merging(new_block->host, size);
> }
> }
> diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
> index b5351e6..c4a0fdd 100644
> --- a/target-s390x/kvm.c
> +++ b/target-s390x/kvm.c
> @@ -331,11 +331,7 @@ static void *legacy_s390_alloc(ram_addr_t size)
> mem = mmap((void *) 0x800000000ULL, size,
> PROT_EXEC|PROT_READ|PROT_WRITE,
> MAP_SHARED | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
> - if (mem == MAP_FAILED) {
> - fprintf(stderr, "Allocating RAM failed\n");
> - abort();
> - }
> - return mem;
> + return mem == MAP_FAILED ? NULL : mem;
> }
>
> int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
> diff --git a/util/oslib-posix.c b/util/oslib-posix.c
> index 3dc8b1b..253bc3d 100644
> --- a/util/oslib-posix.c
> +++ b/util/oslib-posix.c
> @@ -112,9 +112,7 @@ void *qemu_anon_ram_alloc(size_t size)
> size_t offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr;
>
> if (ptr == MAP_FAILED) {
> - fprintf(stderr, "Failed to allocate %zu B: %s\n",
> - size, strerror(errno));
> - abort();
> + return NULL;
> }
>
> ptr += offset;
> diff --git a/util/oslib-win32.c b/util/oslib-win32.c
> index 961fbf5..983b7a2 100644
> --- a/util/oslib-win32.c
> +++ b/util/oslib-win32.c
> @@ -65,10 +65,7 @@ void *qemu_anon_ram_alloc(size_t size)
> /* FIXME: this is not exactly optimal solution since VirtualAlloc
> has 64Kb granularity, but at least it guarantees us that the
> memory is page aligned. */
> - if (!size) {
> - abort();
> - }
> - ptr = qemu_oom_check(VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE));
> + ptr = VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_READWRITE);
> trace_qemu_anon_ram_alloc(size, ptr);
> return ptr;
> }
>
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-07-31 14:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-31 13:11 [Qemu-devel] [PATCH v3 for 1.6 0/8] Guest memory allocation fixes & cleanup Markus Armbruster
2013-07-31 13:11 ` [Qemu-devel] [PATCH v3 for 1.6 1/8] exec: Fix Xen RAM allocation with unusual options Markus Armbruster
2013-07-31 13:11 ` [Qemu-devel] [PATCH v3 for 1.6 2/8] exec: Clean up fall back when -mem-path allocation fails Markus Armbruster
2013-07-31 13:11 ` [Qemu-devel] [PATCH v3 for 1.6 3/8] exec: Reduce ifdeffery around -mem-path Markus Armbruster
2013-07-31 13:11 ` [Qemu-devel] [PATCH v3 for 1.6 4/8] exec: Simplify the guest physical memory allocation hook Markus Armbruster
2013-07-31 13:11 ` [Qemu-devel] [PATCH v3 for 1.6 5/8] exec: Drop incorrect & dead S390 code in qemu_ram_remap() Markus Armbruster
2013-07-31 13:11 ` [Qemu-devel] [PATCH v3 for 1.6 6/8] exec: Clean up unnecessary S390 ifdeffery Markus Armbruster
2013-07-31 13:11 ` [Qemu-devel] [PATCH v3 for 1.6 7/8] exec: Don't abort when we can't allocate guest memory Markus Armbruster
2013-07-31 13:51 ` Andreas Färber [this message]
2013-07-31 13:11 ` [Qemu-devel] [PATCH v3 for 1.6 8/8] pc_sysfw: Fix ISA BIOS init for ridiculously big flash Markus Armbruster
2013-07-31 15:35 ` [Qemu-devel] [PATCH v3 for 1.6 0/8] Guest memory allocation fixes & cleanup Laszlo Ersek
2013-08-16 7:58 ` Markus Armbruster
2013-09-11 13:22 ` Markus Armbruster
2013-09-29 15:15 ` Stefan Weil
2013-09-30 8:39 ` Markus Armbruster
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=51F9164C.8070205@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=armbru@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=mkletzan@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=stefano.stabellini@eu.citrix.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).