Received: by 2002:ab2:6991:0:b0:1f2:fff1:ace7 with SMTP id v17csp194045lqo; Wed, 27 Mar 2024 10:18:31 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXqzvE0OJN/3MlBAb3ErLRO+8ML1/iyfNUPXFM4Ym2FP5mizUnRPoQV1CTN8jYjOA9pH2rL+EpSM5hafAVCmyhxse7hQdZTxlVD3urJlw== X-Google-Smtp-Source: AGHT+IHOtzliJd71NPVhNNk42YywX+kT2Ly03qjvtm64tADIcyFFX5XPzEeCukfoMWxt62DcJCSR X-Received: by 2002:a17:902:eec4:b0:1e1:1d5:f857 with SMTP id h4-20020a170902eec400b001e101d5f857mr324410plb.34.1711559910826; Wed, 27 Mar 2024 10:18:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711559910; cv=pass; d=google.com; s=arc-20160816; b=eyuMuSXP0cwehUTVuqJTGdcPdiiCWRSGNOajR12PMWJ4n22QVyS/+mzua/8o/n4x0K LLEqgerdud956DrEPa7emILmkPdiKopq6qFaYTJgRVhF70C+OIYMoXYLkHT1MMA1tQdn oSBzlLDkzJ+ati2HhRz426pr0PA+HQWC1O8RSd006DNsjj/S6ktLpra91wtmTk+rOusn Y/74t8iZWuIr9hZyjjtMhjw7DyQ0Qn2L+fhAeTmoH//aS7idus3C1izyT0AdyGyvnERF dXdFumCmi95mIZTeMqcsI1OAWnzwxJMHAiQUfoJxNTVYg2pKihk7aYr3Ul37qGLHNDVm 8nDg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=gs7mz2T2Nzxhsdo7I/ZcfY9h1l0ujt1Yaj1fAdyaXDw=; fh=lTN169O21rOOr7J+7lxx3V02qSPUFVwSLBMTyvj5SSQ=; b=JTO4ZLQcdAS70/NJUzifTATJViY89zBK+R6XN0krIMu4YkJDo1NgAZJJWuBq14N3mP jPdrvGzZ0OxmwJsG8u81U+sSoQBPEB/hsuLKdFBD6qPwfd7lAybLk6+lzmFNyYBRt9ZI Ul3HITw8SXYgOOYTtKfK64v/YXhX7Y0Jbp9xznNBgnXtZD48fg+Md/LZ3Z2q95cf13oE Dn7+yZQYjPncshtRhxIuvJm7IpF3ZWjClzdhptOY+5x7OoBS50AweLiwPEqBotIlE1sn nuwygjkZXIhOTXFw4ZKxfyUfi2VcYF1zqF0tVgeUPn+Gwl8R2dCrZuZMZFLYbbq27wKW tA7A==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QlHyqx4J; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-121680-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-121680-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id jf20-20020a170903269400b001e05d7b6a38si9320633plb.400.2024.03.27.10.18.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 10:18:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-121680-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QlHyqx4J; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-121680-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-121680-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 0D866294032 for ; Wed, 27 Mar 2024 17:18:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0F94F14E2ED; Wed, 27 Mar 2024 17:17:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QlHyqx4J" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A50F014E2C4 for ; Wed, 27 Mar 2024 17:17:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711559877; cv=none; b=ABqklHwxPcZl10+x+Mnt1p2/4XFgcBLc3nMfU27zw+H0GNHSlstm5ilDM/IUsmaCYVrw9X1wFecl/iOniYZ8HelGVc2zqYb8HtKQqhZfcK4FgK8Ipb/cTo8yemGf8rrpjqy/lKl05boq966KSCwQrXMUBven2DPiQIbR8POb2CI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711559877; c=relaxed/simple; bh=EdfLc/3/vb1dGCMhQldF+qYp0nlkvEKp1oqt7MkvxwY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=e3D6luoJpktSE4WZbc0QcMkBElpIbw+N4qsf3vszr3JEMYXeqgEGzJi7yk804rhMLH4sEAf7eDhzOwYsPFJYCM6RzikDt7X5RluKdkL9x6A6EnvpNOd408pq6iDL/C/PkDpBLs6p23hsFaj9EbKYoyHhdR9mg9LCO81aVBp3f1g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QlHyqx4J; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711559874; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=gs7mz2T2Nzxhsdo7I/ZcfY9h1l0ujt1Yaj1fAdyaXDw=; b=QlHyqx4J2K5PbSdGQP7f8KwnpuXSovqXb3qVDwPO0OIrVhVHFuQh1LyAMcJtwfdwvSuIOU 4BD8diFXNreZvSPFOtuP1SHXhSW62yjPMCuf6nRQ6s8dd4WdwUwjYCQjnB+x8gx1WhGVZz o7x2cBiBzhzC0Cl9960u9gJcRCBXkjc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-206-ENn_kGGANHuMOOroM-8g4Q-1; Wed, 27 Mar 2024 13:17:49 -0400 X-MC-Unique: ENn_kGGANHuMOOroM-8g4Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9A686101A526; Wed, 27 Mar 2024 17:17:48 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.39.193.208]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0EC5A1121312; Wed, 27 Mar 2024 17:17:43 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Heiko Carstens , Vasily Gorbik , Andrew Morton , Peter Xu , Alexander Gordeev , Sven Schnelle , Gerald Schaefer , Andrea Arcangeli , kvm@vger.kernel.org, linux-s390@vger.kernel.org Subject: [PATCH v2 0/2] s390/mm: shared zeropage + KVM fixes Date: Wed, 27 Mar 2024 18:17:35 +0100 Message-ID: <20240327171737.919590-1-david@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 This series fixes one issue with uffd + shared zeropages on s390x and fixes that "ordinary" KVM guests can make use of shared zeropages again. userfaultfd could currently end up mapping shared zeropages into processes that forbid shared zeropages. This only apples to s390x, relevant for handling PV guests and guests that use storage kets correctly. Fix it by placing a zeroed folio instead of the shared zeropage during UFFDIO_ZEROPAGE instead. I stumbled over this issue while looking into a customer scenario that is using: (1) Memory ballooning for dynamic resizing. Start a VM with, say, 100 GiB and inflate the balloon during boot to 60 GiB. The VM has ~40 GiB available and additional memory can be "fake hotplugged" to the VM later on demand by deflating the balloon. Actual memory overcommit is not desired, so physical memory would only be moved between VMs. (2) Live migration of VMs between sites to evacuate servers in case of emergency. Without the shared zeropage, during (2), the VM would suddenly consume 100 GiB on the migration source and destination. On the migration source, where we don't excpect memory overcommit, we could easilt end up crashing the VM during migration. Independent of that, memory handed back to the hypervisor using "free page reporting" would end up consuming actual memory after the migration on the destination, not getting freed up until reused+freed again. While there might be ways to optimize parts of this in QEMU, we really should just support the shared zeropage again for ordinary VMs. We only expect legcy guests to make use of storage keys, so let's handle zeropages again when enabling storage keys or when enabling PV. To not break userfaultfd like we did in the past, don't zap the shared zeropages, but instead trigger unsharing faults, just like we do for unsharing KSM pages in break_ksm(). Unsharing faults will simply replace the shared zeropage by a zeroed anonymous folio. We can already trigger the same fault path using GUP, when trying to long-term pin a shared zeropage, but also when unmerging a KSM-placed zeropages, so this is nothing new. Patch #1 tested on 86-64 by forcing mm_forbids_zeropage() to be 1, and running the uffd selftests. Patch #2 tested on s390x: the live migration scenario now works as expected, and kvm-unit-tests that trigger usage of skeys work well, whereby I can see detection and unsharing of shared zeropages. Based on Linus master. Andrew agreed that both patches can go via the s390x tree. v1 -> v2: * "mm/userfaultfd: don't place zeropages when zeropages are disallowed" -> Minor "ret" ahndling tweaks * "s390/mm: re-enable the shared zeropage for !PV and !skeys KVM guests" -> Added Fixes: tag Cc: Christian Borntraeger Cc: Janosch Frank Cc: Claudio Imbrenda Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Andrew Morton Cc: Peter Xu Cc: Alexander Gordeev Cc: Sven Schnelle Cc: Gerald Schaefer Cc: Andrea Arcangeli Cc: kvm@vger.kernel.org Cc: linux-s390@vger.kernel.org David Hildenbrand (2): mm/userfaultfd: don't place zeropages when zeropages are disallowed s390/mm: re-enable the shared zeropage for !PV and !skeys KVM guests arch/s390/include/asm/gmap.h | 2 +- arch/s390/include/asm/mmu.h | 5 + arch/s390/include/asm/mmu_context.h | 1 + arch/s390/include/asm/pgtable.h | 15 ++- arch/s390/kvm/kvm-s390.c | 4 +- arch/s390/mm/gmap.c | 163 +++++++++++++++++++++------- mm/userfaultfd.c | 34 ++++++ 7 files changed, 177 insertions(+), 47 deletions(-) -- 2.43.2