From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A15F7C4828F for ; Fri, 9 Feb 2024 15:13:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC1A36B0098; Fri, 9 Feb 2024 10:13:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C70B56B0099; Fri, 9 Feb 2024 10:13:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B12926B009B; Fri, 9 Feb 2024 10:13:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A17AE6B0098 for ; Fri, 9 Feb 2024 10:13:18 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 48E38A0854 for ; Fri, 9 Feb 2024 15:13:18 +0000 (UTC) X-FDA: 81772608876.29.F71B068 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) by imf13.hostedemail.com (Postfix) with ESMTP id 7305C20014 for ; Fri, 9 Feb 2024 15:13:16 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Q7MgawhY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of 3C0HGZQYKCNoOA6JF8CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--seanjc.bounces.google.com designates 209.85.216.73 as permitted sender) smtp.mailfrom=3C0HGZQYKCNoOA6JF8CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707491596; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cgGQ0Ler+WUl/NFsNP3EozyAO4eJj17xtfp/FQdoBaA=; b=rcn1Zbk8o7eSfrAk25nD/26iCfheL7c9heVJzxaOqbrd4eFBamb9hL6mIHVNs3k7LiMlmI TeHrk/sy3GVLc/wuZjygbEpYx7UUxjXC4ly7lEQg+vL3Jf2JAYcEZmQMTlwapoQWxBhbF3 keRNncvSoBM9CJCCWAkaw8YvgXXpPXg= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Q7MgawhY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of 3C0HGZQYKCNoOA6JF8CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--seanjc.bounces.google.com designates 209.85.216.73 as permitted sender) smtp.mailfrom=3C0HGZQYKCNoOA6JF8CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707491596; a=rsa-sha256; cv=none; b=C2ofQbt6PTwHmytEIOKOO07a21b9uzSfWXmvSSRQYM5+l+VZjsQTQy0RHk9/8GYUqVNcXV Pxuhl0hkEzIv22k0uETxVniSts2D8zDrpj6wP4xRSOci65siEFisTh+vYI3V533JpIW9YX FBwd4ZgSpOBUXrcrS64owrxoF9kx7Lc= Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-290c6d7776eso994202a91.2 for ; Fri, 09 Feb 2024 07:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707491595; x=1708096395; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=cgGQ0Ler+WUl/NFsNP3EozyAO4eJj17xtfp/FQdoBaA=; b=Q7MgawhYFcacLO3wiOVqSemdcoDcv3ATnsEAa6Md+LholiHMf7SLJ3wkBoEm2BaB88 H/x1K4vIZaJt9WMrtumlDNU7j1G/qv1IZlVQd5LL7SpbCJdTBPbK7PGo++W6JokXSFN1 bUK6KRyfGuDNehUoxwBsk1L3WsfIBchycE3xoDk5Vivwc3uxIVEyjaNLwaenl4ehRbw1 f8JXeb5sm+QbnEmRiapujo9Nl7U6d+Q16KN1lB28wWArPWm7yHqi9N3/ASfZzdK8AvJY jqs0Vg1LzK9Pm1puznEXCWCxic2DfkNsCVhb8VNAMeDIsieuD8r87lb6DWFhrtoEvkJx BwIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707491595; x=1708096395; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cgGQ0Ler+WUl/NFsNP3EozyAO4eJj17xtfp/FQdoBaA=; b=cXAlitGFGAHy/XkAlV0A6KFYgKgur4K3MBYAtcPzSfJ4gFvywrGD2FQv8E9OrKJ+av lgqt5SKZDO45V85Fi5sRlcEMFjvIZEpKK9MiW51z+IaeAgrjMD91GjsGnb/qzOm0EkcK eV5htSheL2tSD/cmzK3TqjbGG3OPd8/11oMoqr/KOGE3Ljy/KAldS49A2YCXob4hvCh3 DCmfup09RIA25wYyfFiINJJhPsEnI0/Z+FLSHtMxKM6lD1ih/XTzDasL6IXDduketff7 O8aK1qePoZ4DbCUrmPY53Ajww0uGUBTDYVcFRaYPIYWlbqG5SibHL0KL3jjFA8WGk2Wx ftyQ== X-Forwarded-Encrypted: i=1; AJvYcCUTrPffVee9VvNKDMS47eblkknxLozGxT4K2GbvDa27C8DEtWRkTgE/ghdfTTB60bQuCbo8aawOTulwEPayZbiF8Bk= X-Gm-Message-State: AOJu0YzWf9Zg4O/5WilJHjo1mg1gCxfHXl3Pz3X4LGD7WW6wvAD0d6QG W6iAh20xh1uUDZW+yMvSIo1iCchbIe69pVqaZNcHlT63Ck3Ik45whdGtn2cLS6rz9898+94mShN qCA== X-Google-Smtp-Source: AGHT+IGnxQ9hUZq2I0deBQMbaG7FpVg+3DEJAeDot7uWCeqlyGYIqcr+64bku6EdOLuv7fFuPPSWAvWzMMw= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:2781:b0:296:aa24:8bc3 with SMTP id pw1-20020a17090b278100b00296aa248bc3mr23980pjb.5.1707491595319; Fri, 09 Feb 2024 07:13:15 -0800 (PST) Date: Fri, 9 Feb 2024 07:13:13 -0800 In-Reply-To: <84d62953-527d-4837-acf8-315391f4b225@arm.com> Mime-Version: 1.0 References: <20231016115028.996656-1-michael.roth@amd.com> <20231016115028.996656-5-michael.roth@amd.com> <84d62953-527d-4837-acf8-315391f4b225@arm.com> Message-ID: Subject: Re: [PATCH RFC gmem v1 4/8] KVM: x86: Add gmem hook for invalidating memory From: Sean Christopherson To: Steven Price Cc: Michael Roth , kvm@vger.kernel.org, Suzuki K Poulose , "tabba@google.com" , linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, pbonzini@redhat.com, isaku.yamahata@intel.com, ackerleytng@google.com, vbabka@suse.cz, ashish.kalra@amd.com, nikunj.dadhania@amd.com, jroedel@suse.de, pankaj.gupta@amd.com Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 7305C20014 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 6p4rrhq5yx17ftgdzh4ydfdy9ccewc5p X-HE-Tag: 1707491596-354556 X-HE-Meta: U2FsdGVkX1/yAdXSF/chmDWBlzc1bnMWN0D939ajIzctsf93Q6iOMQ2nSjRBwYltL2BYrprr31IsjZCkoWBAE9QQqXQwJ6wiKye5me0xp7VNCLxny5goCEiSSksOy/NcAVP3BVMf7vm21/j1DIE0KDnRODZD/X3BSHALi4TzNMHCANlWoWiMEUkpFtNIQKIjv81DpILwfBvHtyOlUF6JoBiEspAGl8ZfMYCmzsR7e12UbE1fxHfjYAe/fLJSWjthLhw2VQe3kbFq5vohnsCWnwcQlBjnlz/fK2icLacC9WGkiujUxzhGuFaXu5cJVFzamn0yPb6GK4SZwm5/b3C9bj5VvP+TFsOHInFsbKoiG7tXTOflWGVKV8A2zSG3LXVE0HxZejSvmq0rcyEetVF7UlZdwWj7nyQMR0oAwixDgALV6HNmoraoPcVj/QxoWMEL2xSp5geORA5t6JNout5dzwzSfSyvHcobRnns8TN9XB1+CbR++0bPuFj1kb9nRa0LMWlFotIVeYkV4e2NKJeq8C1AjaYrsgPJAAeyC7dgUjP8wsw+enQdpAd0VzXt7NHy6hiP9d2gF9ybjAirKUmcYLolZUJY0F82EAREiym+RE1iAi3MbDK7J6uQYu1soexIOhW6iUHpCMhtl1MiG4XOiq+clYtwtG7LP9lwCuhPpLWOPNQOifQpb/zt+CNPfsjAJog2EC7wpbMA9TD63zLAXDmQYGdW3yOU4RBUyacr/u+Y+HEm6OSRpbxgwKY7JxW00Ti7mUL+P56DrL6uHh4trPpSMWl2AqGHaXGkcIhYW0/LwiKg3zwzXq3J30zZO8durZAe2EvxfYrM+7BourD2ItmfL6zyoGO/UMae6RNTpeVpr9LXQtXmDPIZHkx0XGfPpaPhSpcO/cNdEPkgrEoVbl3VLr4Wst0UH/iEOhA8G20O8Q/izl0eabZROXRR1yA2cVSKS3rywcHDgBVGw2/ T/c5zhNr EQS49bO+7TtT5tB2OK5W+g2eY6lZj+2ci6LwYvRzT3bFylLiwWw6wh0/PshXdd2q+24DBHzojuF6UrYkoShE/fnwz+OWOZ5qSePBS7db2K8z7Px/kw+oh3LMdUTzP14kgRbhutrhUo48Lzyj6A1NpfRwJAi6amKrT+gsv16c46MnOi3sRIvWXZhRaqFKrixUfnCZl7LEMtg7rev3otYI+yl9YX0gNahoc9DY+qGev8bH8zTp9Nl+pwDgvowKgWdbwFrzmaOU2YovEIH11lwDx2krqlGd9o2U7XzWuNHndB1iuFdrE43wihvNXNkQsCE6mvZir+DEBTxxgOZ/mJiraTlL5mdX1IYglxg5BLG17LFPNgWYOfhc/dkxb4tFxZOsp37RXRFCmX61Q+g2kf5YvgVrRCezo+LicncAbjZ9cG0vmmxALy+v/Og3AJPvvhYlC+7elbDLmUncO+NNPCi+dAkUjZiI3DSEgBWSvk7njT89DkZmC4UWD6HY+XzCisrOCk2qWiRxdjxeFmYwOloWdM91oYhJUATwwBICFn39ioDsyjVo30f1Gik2PiE1963hq5WiNb12x83YerK/eSKsCDaY6G606rTNSUJ0NMLrRCmfFA56xj2MdvqGCN9mwfKexjMLF2rdEWNa1tBiQudRmCH+Nkk2qVCkItd1sLomeVMgCl3FCVQVszQ7Tq/Uy0UeppTaKHLamhdT8HwRuu7hYtz2vaxQoEZtzF65u X-Bogosity: Ham, tests=bogofilter, spamicity=0.001282, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Feb 09, 2024, Steven Price wrote: > >> One option that I've considered is to implement a seperate CCA ioctl to > >> notify KVM whether the memory should be mapped protected. > > > > That's what KVM_SET_MEMORY_ATTRIBUTES+KVM_MEMORY_ATTRIBUTE_PRIVATE is for, no? > > Sorry, I really didn't explain that well. Yes effectively this is the > attribute flag, but there's corner cases for destruction of the VM. My > thought was that if the VMM wanted to tear down part of the protected > range (without making it shared) then a separate ioctl would be needed > to notify KVM of the unmap. No new uAPI should be needed, because the only scenario time a benign VMM should do this is if the guest also knows the memory is being removed, in which case PUNCH_HOLE will suffice. > >> This 'solves' the problem nicely except for the case where the VMM > >> deliberately punches holes in memory which the guest is using. > > > > I don't see what problem there is to solve in this case. PUNCH_HOLE is destructive, > > so don't do that. > > A well behaving VMM wouldn't PUNCH_HOLE when the guest is using it, but > my concern here is a VMM which is trying to break the host. In this case > either the PUNCH_HOLE needs to fail, or we actually need to recover the > memory from the guest (effectively killing the guest in the process). The latter. IIRC, we talked about this exact case somewhere in the hour-long rambling discussion on guest_memfd at PUCK[1]. And we've definitely discussed this multiple times on-list, though I don't know that there is a single thread that captures the entire plan. The TL;DR is that gmem will invoke an arch hook for every "struct kvm_gmem" instance that's attached to a given guest_memfd inode when a page is being fully removed, i.e. when a page is being freed back to the normal memory pool. Something like this proposed SNP patch[2]. Mike, do have WIP patches you can share? [1] https://drive.google.com/corp/drive/folders/116YTH1h9yBZmjqeJc03cV4_AhSe-VBkc?resourcekey=0-sOGeFEUi60-znJJmZBsTHQ [2] https://lore.kernel.org/all/20231230172351.574091-30-michael.roth@amd.com