From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swlas-0001GQ-Ib for qemu-devel@nongnu.org; Wed, 01 Aug 2012 22:56:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Swlar-0003Lr-5H for qemu-devel@nongnu.org; Wed, 01 Aug 2012 22:56:58 -0400 Received: from ozlabs.org ([203.10.76.45]:57340) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swlaq-0003Jt-Pu for qemu-devel@nongnu.org; Wed, 01 Aug 2012 22:56:57 -0400 Date: Thu, 2 Aug 2012 12:56:58 +1000 From: David Gibson Message-ID: <20120802025658.GA7521@truffala.fritz.box> References: <1343796065-871-1-git-send-email-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1343796065-871-1-git-send-email-david@gibson.dropbear.id.au> Subject: Re: [Qemu-devel] [PATCH] Remove ill-advised fallback when we cannot allocate from -mem-path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: motosatti@redhat.com Cc: qemu-devel@nongnu.org Marcelo, Anthony pointed out that you explicitly added this fallback in 618a568da4eda5c2e41fc4e58059546806afff6b. I'd like to know your reasoning as to why - as noted below this causes problems for us, and a situation where the fallback is desirable is not clear to me. On Wed, Aug 01, 2012 at 02:41:05PM +1000, David Gibson wrote: > When the -mem-path option is specified we try to allocate memory for guest > RAM from mmap()ing files in the given path rather than from anonymous > memory as usual. If we are unable to allocate memory from the path, we > fall back to anonymous memory, with a rather cryptic error message. > > This fallback is a bad idea - if the user specified a backing path, they > did so for a reason and falling back automatically could lead to confusing > results. > > Under Book3S-HV KVM on PowerPC the failure is particularly bad, because the > page size of the backing file limits what page sizes can be supported in the > guest. We have code to automatically advertise the available page sizes to > the guest, but this will give the wrong information in the case of a fall > back to anonymous memory, because by the time we're producing that infor > there's no easy way to determine that such a fallback occurred. > > Signed-off-by: David Gibson > --- > exec.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/exec.c b/exec.c > index feb4795..544a090 100644 > --- a/exec.c > +++ b/exec.c > @@ -2425,7 +2425,6 @@ static void *file_ram_alloc(RAMBlock *block, > area = mmap(0, memory, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0); > #endif > if (area == MAP_FAILED) { > - perror("file_ram_alloc: can't mmap RAM pages"); > close(fd); > return (NULL); > } > @@ -2528,8 +2527,9 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host, > #if defined (__linux__) && !defined(TARGET_S390X) > new_block->host = file_ram_alloc(new_block, size, mem_path); > if (!new_block->host) { > - new_block->host = qemu_vmalloc(size); > - qemu_madvise(new_block->host, size, QEMU_MADV_MERGEABLE); > + fprintf(stderr, "Unable to map %llu bytes of RAM from requested" > + " backing path %s\n", (unsigned long long)size, mem_path); > + exit(1); > } > #else > fprintf(stderr, "-mem-path option unsupported\n"); -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson