From nobody Sat Nov 8 10:42:50 2025 Delivered-To: importer@patchew.org Received-SPF: temperror (zoho.com: Error in retrieving data from DNS) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=temperror (zoho.com: Error in retrieving data from DNS) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1550119591564336.15361365485796; Wed, 13 Feb 2019 20:46:31 -0800 (PST) Received: from localhost ([127.0.0.1]:40038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gu8ul-0006fz-GE for importer@patchew.org; Wed, 13 Feb 2019 23:46:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gu8p7-0002G8-3M for qemu-devel@nongnu.org; Wed, 13 Feb 2019 23:40:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gu8os-0006yt-OW for qemu-devel@nongnu.org; Wed, 13 Feb 2019 23:40:26 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:53275) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gu8oh-0006OY-2l; Wed, 13 Feb 2019 23:40:09 -0500 Received: by ozlabs.org (Postfix, from userid 1007) id 440Nvr395Nz9sN4; Thu, 14 Feb 2019 15:39:20 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1550119160; bh=nWRdTR7bVRlVF/K07KuGeCKDx4BJXMraKKIyCPjHuuY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hmE5Mm6rI2JRUhQ2ZUUNV7Z4/l9QXW9sPvLzSrsxDVmeVQ8pBzpdTJjCYIaxIXQpk DqnMfHDv0Xhcdrrd4TDQa2m8DZRo3xKR3vyfwmTeMCxtLav6ZLVdbgc6deFnpxQDVV NoDu5VjCThcMkyl44C7YqrRLvKDXPaP3zRfzoScw= From: David Gibson To: mst@redhat.com, qemu-devel@nongnu.org Date: Thu, 14 Feb 2019 15:39:15 +1100 Message-Id: <20190214043916.22128-5-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190214043916.22128-1-david@gibson.dropbear.id.au> References: <20190214043916.22128-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2401:3900:2:1::2 Subject: [Qemu-devel] [PATCH 4/5] virtio-balloon: Use ram_block_discard_range() instead of raw madvise() X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-ppc@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" Currently, virtio-balloon uses madvise() with MADV_DONTNEED to actually discard RAM pages inserted into the balloon. This is basically a Linux only interface (MADV_DONTNEED exists on some other platforms, but doesn't always have the same semantics). It also doesn't work on hugepages and has some other limitations. It turns out that postcopy also needs to discard chunks of memory, and uses a better interface for it: ram_block_discard_range(). It doesn't cover every case, but it covers more than going direct to madvise() and this gives us a single place to update for more possibilities in future. There are some subtleties here to maintain the current balloon behaviour: * For now, we just ignore requests to balloon in a hugepage backed region. That matches current behaviour, because MADV_DONTNEED on a hugepage would simply fail, and we ignore the error. * If host page size is > BALLOON_PAGE_SIZE we can frequently call this on non-host-page-aligned addresses. These would also fail in madvise(), which we then ignored. ram_block_discard_range() error_report()s calls on unaligned addresses, so we explicitly check that case to avoid spamming the logs. * We now call ram_block_discard_range() with the *host* page size, whereas we previously called madvise() with BALLOON_PAGE_SIZE. Surprisingly, this also matches existing behaviour. Although the kernel fails madvise on unaligned addresses, it will round unaligned sizes *up* to the host page size. Yes, this means that if BALLOON_PAGE_SIZE < guest page size we can incorrectly discard more memory than the guest asked us to. I'm planning to address that soon. Errors other than the ones discussed above, will now be reported by ram_block_discard_range(), rather than silently ignored, which means we have a much better chance of seeing when something is going wrong. Signed-off-by: David Gibson Reviewed-by: Michael S. Tsirkin --- hw/virtio/virtio-balloon.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c index bf93148486..e4cd8d566b 100644 --- a/hw/virtio/virtio-balloon.c +++ b/hw/virtio/virtio-balloon.c @@ -37,8 +37,29 @@ static void balloon_inflate_page(VirtIOBalloon *balloon, MemoryRegion *mr, hwaddr offset) { void *addr =3D memory_region_get_ram_ptr(mr) + offset; + RAMBlock *rb; + size_t rb_page_size; + ram_addr_t ram_offset; =20 - qemu_madvise(addr, BALLOON_PAGE_SIZE, QEMU_MADV_DONTNEED); + /* XXX is there a better way to get to the RAMBlock than via a + * host address? */ + rb =3D qemu_ram_block_from_host(addr, false, &ram_offset); + rb_page_size =3D qemu_ram_pagesize(rb); + + /* Silently ignore hugepage RAM blocks */ + if (rb_page_size !=3D getpagesize()) { + return; + } + + /* Silently ignore unaligned requests */ + if (ram_offset & (rb_page_size - 1)) { + return; + } + + ram_block_discard_range(rb, ram_offset, rb_page_size); + /* We ignore errors from ram_block_discard_range(), because it has + * already reported them, and failing to discard a balloon page is + * not fatal */ } =20 static const char *balloon_stat_names[] =3D { --=20 2.20.1