From patchwork Tue Mar 15 17:35:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 8590861 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9D590C0553 for ; Tue, 15 Mar 2016 17:37:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D82FF20204 for ; Tue, 15 Mar 2016 17:37:38 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2323A2011B for ; Tue, 15 Mar 2016 17:37:38 +0000 (UTC) Received: from localhost ([::1]:50291 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afsuX-0001pA-Hg for patchwork-qemu-devel@patchwork.kernel.org; Tue, 15 Mar 2016 13:37:37 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afssK-0006I8-NB for qemu-devel@nongnu.org; Tue, 15 Mar 2016 13:35:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afssJ-0003me-MI for qemu-devel@nongnu.org; Tue, 15 Mar 2016 13:35:20 -0400 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:36217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afssJ-0003mZ-CP for qemu-devel@nongnu.org; Tue, 15 Mar 2016 13:35:19 -0400 Received: by mail-wm0-x229.google.com with SMTP id l124so20063866wmf.1 for ; Tue, 15 Mar 2016 10:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references; bh=ZovN+IwuY+3r5VTdm3XXI5bTBIX1zIy5j95AWVwvIUA=; b=yNNgwIyNV/ETyB7j9jM4gGM91Ry0UvQjfgU7dlz8MZ6rdq2vtKfFGrW9ZtxtOP1yzb Eehug9sGCS7FEdEcgN+y12fu+ui2mhPmwAd3XLKYx4wLZlA3fVO0uFIB4NKaqZXBne4u TCU9r2WLu6ZI53USefP3/0yb4H2xigp2tnVqLpfx8Mt2/1I9MyZ8OW6xgPWZFx+icr9S wsPFIBBbheUJYoNq9FM0XX7N9ihyIyYDHmASf9EeOn7lzCnfx2yn4vKkgCVWRDPzUOUv WBZpqPzogpLu7czTHCSZRDkgwYODz6SWDkzEa63lnwoEEwuYqefxzS9rT46mraNhy4Fq HJ5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references; bh=ZovN+IwuY+3r5VTdm3XXI5bTBIX1zIy5j95AWVwvIUA=; b=AY1JUvmXBJFUqiyCn8LuJJdDUNFFUFwtyE7ugixTyxbM1ftXRvscD/Gk0RUoOxhVaK o2khWZ1gmWPQRx/wJXQGtAEO8HzzTjjLLVVpbk13Oj1WPfDEMyme2oESKblkRngRgbap lCYdefnWmSo4pOLSVBmOgH1cM9tolrTc5x4T1qOF53J1X6UzxOjHx57nK/Vo1vO9/bE9 KAj5au4TCrdB64vm0WnwLYF800rG1F02F9glthmr9DP4E8L4rquK81cjq3s2qkdkxPJa GKEAF90F/qk1d02N+6r+qm2zE5N4jxsv6U1oSsPh2RNcgZbkBSFgJqculdZ4b0lm7jEj ElWA== X-Gm-Message-State: AD7BkJIZYGTS3xbpyJnjY7hgqZB9NCIIMn+frguW97asBu0FCun5uIVkbQYdQT/EW0+CKA== X-Received: by 10.194.189.143 with SMTP id gi15mr30815033wjc.54.1458063318708; Tue, 15 Mar 2016 10:35:18 -0700 (PDT) Received: from 640k.lan (94-39-161-17.adsl-ull.clienti.tiscali.it. [94.39.161.17]) by smtp.gmail.com with ESMTPSA id z127sm21827680wme.5.2016.03.15.10.35.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Mar 2016 10:35:18 -0700 (PDT) From: Paolo Bonzini To: qemu-devel@nongnu.org Date: Tue, 15 Mar 2016 18:35:06 +0100 Message-Id: <1458063310-128525-5-git-send-email-pbonzini@redhat.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1458063310-128525-1-git-send-email-pbonzini@redhat.com> References: <1458063310-128525-1-git-send-email-pbonzini@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::229 Cc: Markus Armbruster Subject: [Qemu-devel] [PULL 4/8] exec: Fix memory allocation when memory path isn't on hugetlbfs X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Markus Armbruster gethugepagesize() works reliably only when its argument is on hugetlbfs. When it's not, it returns the filesystem's "optimal transfer block size", which may or may not be the actual page size you'll get when you mmap(). If the value is too small or not a power of two, we fail qemu_ram_mmap()'s assertions. These were added in commit 794e8f3 (v2.5.0). The bug's impact before that is currently unknown. Seems fairly unlikely at least when the normal page size is 4KiB. Else, if the value is too large, we align more strictly than necessary. gethugepagesize() goes back to commit c902760 (v0.13). That commit clearly intended gethugepagesize() to be used on hugetlbfs only. Not only was it named accordingly, it also printed a warning when used on anything else. However, the commit neglected to spell out the restriction in user documentation of -mem-path. Commit bfc2a1a (v2.5.0) dropped the warning as bogus "because QEMU functions perfectly well with the path on a regular tmpfs filesystem". It sure does when you're sufficiently lucky. In my testing, I was lucky, too. Fix by switching to qemu_fd_getpagesize(). Rename the variable holding its result from hpagesize to page_size. Cc: Paolo Bonzini Signed-off-by: Markus Armbruster Message-Id: <1457378754-21649-3-git-send-email-armbru@redhat.com> Signed-off-by: Paolo Bonzini --- exec.c | 40 +++++++--------------------------------- 1 file changed, 7 insertions(+), 33 deletions(-) diff --git a/exec.c b/exec.c index 3380836..274b619 100644 --- a/exec.c +++ b/exec.c @@ -1228,27 +1228,6 @@ void qemu_mutex_unlock_ramlist(void) } #ifdef __linux__ - -#include - -#define HUGETLBFS_MAGIC 0x958458f6 - -static long gethugepagesize(int fd) -{ - struct statfs fs; - int ret; - - do { - ret = fstatfs(fd, &fs); - } while (ret != 0 && errno == EINTR); - - if (ret != 0) { - return -1; - } - - return fs.f_bsize; -} - static void *file_ram_alloc(RAMBlock *block, ram_addr_t memory, const char *path, @@ -1260,7 +1239,7 @@ static void *file_ram_alloc(RAMBlock *block, char *c; void *area; int fd; - int64_t hpagesize; + int64_t page_size; if (kvm_enabled() && !kvm_has_sync_mmu()) { error_setg(errp, @@ -1315,22 +1294,17 @@ static void *file_ram_alloc(RAMBlock *block, */ } - hpagesize = gethugepagesize(fd); - if (hpagesize < 0) { - error_setg_errno(errp, errno, "can't get page size for %s", - path); - goto error; - } - block->mr->align = hpagesize; + page_size = qemu_fd_getpagesize(fd); + block->mr->align = page_size; - if (memory < hpagesize) { + if (memory < page_size) { error_setg(errp, "memory size 0x" RAM_ADDR_FMT " must be equal to " "or larger than page size 0x%" PRIx64, - memory, hpagesize); + memory, page_size); goto error; } - memory = ROUND_UP(memory, hpagesize); + memory = ROUND_UP(memory, page_size); /* * ftruncate is not supported by hugetlbfs in older @@ -1342,7 +1316,7 @@ static void *file_ram_alloc(RAMBlock *block, perror("ftruncate"); } - area = qemu_ram_mmap(fd, memory, hpagesize, block->flags & RAM_SHARED); + area = qemu_ram_mmap(fd, memory, page_size, block->flags & RAM_SHARED); if (area == MAP_FAILED) { error_setg_errno(errp, errno, "unable to map backing store for guest RAM");