From patchwork Fri Jul 6 18:50:11 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Tokarev X-Patchwork-Id: 1166931 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 9DABA3FC33 for ; Fri, 6 Jul 2012 18:50:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757567Ab2GFSuQ (ORCPT ); Fri, 6 Jul 2012 14:50:16 -0400 Received: from isrv.corpit.ru ([86.62.121.231]:46359 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757440Ab2GFSuP (ORCPT ); Fri, 6 Jul 2012 14:50:15 -0400 Received: from [192.168.88.2] (mjt.vpn.tls.msk.ru [192.168.177.99]) by isrv.corpit.ru (Postfix) with ESMTP id 3589FA0484; Fri, 6 Jul 2012 22:50:13 +0400 (MSK) Message-ID: <4FF73363.1080409@msgid.tls.msk.ru> Date: Fri, 06 Jul 2012 22:50:11 +0400 From: Michael Tokarev Organization: Telecom Service, JSC User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Avi Kivity CC: Blue Swirl , Marcelo Tosatti , Jan Kiszka , qemu-devel@nongnu.org, kvm@vger.kernel.org Subject: Re: [Qemu-devel] [PATCH] kvm: align ram_size to page boundary References: <1339922831-23002-1-git-send-email-avi@redhat.com> <4FDDB981.8070309@web.de> <4FDDBFCD.3000608@redhat.com> <4FDDC3C8.5020205@web.de> <4FDDC4B6.5030202@redhat.com> <4FDDD39D.9090800@redhat.com> <4FDDD818.4030700@redhat.com> In-Reply-To: <4FDDD818.4030700@redhat.com> X-Enigmail-Version: 1.4.1 OpenPGP: id=804465C5 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 17.06.2012 17:14, Avi Kivity wrote: > On 06/17/2012 04:06 PM, Blue Swirl wrote: > >>> strtosz() is much too general. We could do it in vl.c without trouble. >>> However, it takes away our ability to emulate a "640k should be enough >>> for everyone" machine. >> >> Then how about current max of target page sizes: 8k? No machine should >> want less than that. > > Okay by me, but I can hear the we-should-have-a-generic-mechanism crowd > charging their megaphone batteries. So, is there some bottom line in that? I think I'll put a (temp) fix/workaround for the debian package to require memory size to be a multiple of 8K, and to produce a warning if that requiriment hasn't met. Something like this: With this patch, running qemu-system-x86_64 -m 1.4g produces the following: warning: requested memory size (1503238553 bytes) truncated to 1503232000 bytes Thanks, /mjt --- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/vl.c b/vl.c index 5d9fc55..db98a4a 100644 --- a/vl.c +++ b/vl.c @@ -2671,7 +2675,15 @@ int main(int argc, char **argv, char **envp) fprintf(stderr, "qemu: ram size too large\n"); exit(1); } - ram_size = value; +#define RAM_SIZE_GRANULARITY (8*1024) + ram_size = value / RAM_SIZE_GRANULARITY; + ram_size *= RAM_SIZE_GRANULARITY; + if (ram_size != value) { + fprintf(stderr, + "warning: requested memory size (%" PRIu64 " bytes) " + "truncated to %" PRIu64 " bytes\n", + value, (uint64_t)ram_size); + } break; } case QEMU_OPTION_mempath: