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 7774FC54E58 for ; Tue, 12 Mar 2024 20:26:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8B216B0201; Tue, 12 Mar 2024 16:26:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E16996B0202; Tue, 12 Mar 2024 16:26:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB4A86B0203; Tue, 12 Mar 2024 16:26:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B4CAC6B0201 for ; Tue, 12 Mar 2024 16:26:46 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 302E216018C for ; Tue, 12 Mar 2024 20:26:46 +0000 (UTC) X-FDA: 81889520412.28.C088D9F Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf01.hostedemail.com (Postfix) with ESMTP id 8F0434000A for ; Tue, 12 Mar 2024 20:26:44 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="AG/7MzrP"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of 3g7rwZQYKCPAkWSfbUYggYdW.Ugedafmp-eecnSUc.gjY@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3g7rwZQYKCPAkWSfbUYggYdW.Ugedafmp-eecnSUc.gjY@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710275204; 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=qkdeVHiZ4dO2mKNOI6prWlI/035w5V9mRcS9wJoax+0=; b=J8b/Agfm+dbS5uSfq/Ho88JMruVE7woLJRXWmjc8nk/OnRJj7UcJw83tF8e5xp3c1v4oTI cLFEgaiwGrpRg9a/Fu78EQuZy5XEFYNau5ZH11Jfk31Po57f6mEAii5Ao2B6rf3f9AiS5P bVkS3wYU6lbpPwhRV4ldna6vJ4hIsiU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="AG/7MzrP"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of 3g7rwZQYKCPAkWSfbUYggYdW.Ugedafmp-eecnSUc.gjY@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3g7rwZQYKCPAkWSfbUYggYdW.Ugedafmp-eecnSUc.gjY@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710275204; a=rsa-sha256; cv=none; b=qfrOgsJKxJveJR5SHjENCxpewJkNxy7lflQ0HEPg2Ge32kjs+NLlFGS7+ap2gwWwsQRSYF S43rxLzrjg1DjPfeutuB0CcW0IVehQJ85w4WeIim8aEJaGFnOROXPuxNnBrLE7RRJf2mfV mxoSa0hWe8tsdCWr/CeDBKOzF1OYpqo= Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-dcbee93a3e1so7728362276.3 for ; Tue, 12 Mar 2024 13:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710275203; x=1710880003; 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=qkdeVHiZ4dO2mKNOI6prWlI/035w5V9mRcS9wJoax+0=; b=AG/7MzrPoGHIjFar22vRR5uJtC49p+/XtMOOFl3s0DEyEkaBTdK0BbrPlA9ahs0eiZ CyS+dAuy6rNDVYpCWPJZstbuNPJ30RKEV0VYyBuhwrCBNacVnV860qp2buBVxoyarhUx j0+E0Oap/J1d5nCVGi6QYpSa7jWf8Cdslv2MCPKdyng91Cin5BK/ITRID67IZME72Mt2 uL0b6nPY0qE+gwW4Nox8DJ0D/w0wly1LtEgti9pV+tSQ5Vi2cyA7nw28qwCebg3BtZ4q uLMeD8wHLgeWIzHfZ9V+/wxYa+ykOhFFsVhOI0sK2ZuVNRxos+wS9kF0zjp0O6BXwJD6 QGtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710275203; x=1710880003; 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=qkdeVHiZ4dO2mKNOI6prWlI/035w5V9mRcS9wJoax+0=; b=E0YqZobCllXaUE4RUcEFSsysBRFkTFrMBespixk2gNiBkQxQzJ3gkzY7+SZbliCENe B1R/yTLatC74jpDJwqMx16fqWW8yzJci9ihHxQ1W6Kw95Q0FU2kmu+b5Z4FDJ8avYkVp 9t0Mmn8E4kD5ox+q9FJl5+ZMFqVkvW5d13DbIje8rNQZyX3lLy5w7+jHGM37I7c7Ehe5 7xbMnj7L/0QHtmguqXUVadKpybJh1JRtdQMURzgdKbPj8PScI7h+vlEvKJuMcrjIcbt+ JO4xdaUgrP1fFWcDJ90JIGudY1EBl75qlXQsnfrMcuUVaDjw06giWY2ZTbEr2Aj/zUa1 m+oA== X-Forwarded-Encrypted: i=1; AJvYcCXqwvOZqL8OjvCs9DQ8Mv2sHu/A5vROfo1GlBKBot6d/mhCaCxQ8bHLA7fW/fQFfqN7dQuzedjyS+wZ+ZZxVSC8Gao= X-Gm-Message-State: AOJu0YzWcaZNkngqIZekjQhxTvpTd/Abt633GuoRrwRtqKG2651AP+Mf 3jLIXFkfPHhEwNV/nofug0uPZ5Dpi0fkvIZwGXmncGrmaql3LWjFbqexlKk8oF/hIjHWLG/YGb8 QmQ== X-Google-Smtp-Source: AGHT+IFUmGhOgcd89e4lrqvlrIUFlYT8TKtqW8wVsN51aYrWhEhHnUI06gztJWUkIbtg80Ly0GbAPRIO8Ug= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:114a:b0:dc6:d890:1a97 with SMTP id p10-20020a056902114a00b00dc6d8901a97mr59614ybu.9.1710275203718; Tue, 12 Mar 2024 13:26:43 -0700 (PDT) Date: Tue, 12 Mar 2024 13:26:42 -0700 In-Reply-To: <20240311172431.zqymfqd4xlpd3pft@amd.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> <20240311172431.zqymfqd4xlpd3pft@amd.com> Message-ID: Subject: Re: [PATCH RFC gmem v1 4/8] KVM: x86: Add gmem hook for invalidating memory From: Sean Christopherson To: Michael Roth Cc: Steven Price , 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: 8F0434000A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: d1uydh7djo81o63a9ketwca18gf84owr X-HE-Tag: 1710275204-737389 X-HE-Meta: U2FsdGVkX19WuwLm3R7idm3+Ztwwwtpz1PuDlPFKoHy8c+qUQR+1XTsRdx/uWEFWwztJNdzU/tfmz0V5JHHbGqg+GpYTUo0ySUThEGqkAQ1k9JKBxdiJy01QznGN0a6r9OgLKeL0081FQBomZCmplcq56a8WMJROZlD9f8ph4kzxmqBMp6S/Ce+0PsNt42b3yOeWw+tsSA95rOyhjaEFWd7qej5c1bNNyO0iQvJYd7pTU5AtLrR5bCxxwDFwxNPdUyDHbzfqqxz2HKJlJJydY2x29eNWBvhS5yIMVm5jg07yB/BemLeapI//hMbVn6vmTdurwAAMsbDEp2D/jX8Qs8QBzMiQ31UBx16DaGSF8xYumwGpJpqtLTXe2ytCFzLj9oncvQ690lMhm2dOMiaJ1QXdf5yW8d/SUvlXXkS4Xer0MZg6JzO0XywKzVIPPbsc/IuGJJ5G3gEPNdOmvNX3VC6pzJgMOvo+VnplKEgn/TjKJB8ik9xlAeAFMqKUjOPqUPHcQ2nke+mqEOJrX672PhKYDmO8tC2SzREcH/nfnEjQrRgoZWfvNJiTEPHd9StoJ5RbpXkbTGfPzvsSFyjR+GLTSwiOwz4SyUKPit1dbUELVo4ViIqwNh5lhOYbmHjVbD57Fe48/sE79B2dsUmhfYIw0/h+w8TgILzdDyFAF8vApM5JjaxpClffVcg34hGnqLNrhQKWuZLxu3ItZRe5p6nui16tGfJBSaYnLkAUxoaEM1GjPrihwbBmIzU8I57l1oImEeToPhx0OsXHJh4V85EanAl2pCn0WD4F3IiQKXslT6H3qiqYmgxJvO+oQjw/SrFnsFfugSD4EVYuG0efLS275uXYPP6hq8Xx7n0md8t9xBBNcexz1/9ozQGmVFcujsTQNtaf91uy+vU0zg83QgZYSJjAOjMcDobyw/hDgxxskV2IEM05AVUZyaveYPQa4WZiFyVYJNW9JpzzRcu SMCeQ+Us dc37O3GGpxOdFtdsn8sWJ9zS0CwCN9yGLmyXZ0YwsQSuSD1FoTL/ANZ44SNsrllXy2/v0ZXVi48VlXzWmDxtEA/KDnbBNaEpc3AVfx6JFiQsW2cW+oXYpEKCp7xleDNMK8qtQl126wzAG8DL5/FPIPN2WppKKmh09UO6EKR9c7UWpKku6HEpgJDzN2kPL2I+A21F1XZh9dXhPzAroDCqL89NzB6X7srQlwF67w2R0enLr8BWVGwGZwVi/fIkULg88Qk74iv1o85VDY6BB9GBl7K00kj6Nb1mDAJ9PDTP8+XcSNNoeugnn8gHLo7lUSpNrWR78WMcCZ+y4mmbh/QD6FfqUCJiyxNOKOc2ZlCyVDZ1YTkTbQND+k6IST6UPZIl50FQyuWcIcJAAurY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Mon, Mar 11, 2024, Michael Roth wrote: > On Fri, Feb 09, 2024 at 07:13:13AM -0800, Sean Christopherson wrote: > > 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? > > Sorry, I missed this query earlier. I'm a bit confused though, I thought > the kvm_arch_gmem_invalidate() hook provided in this patch was what we > ended up agreeing on during the PUCK call in question. Heh, I trust your memory of things far more than I trust mine. I'm just proving Cunningham's Law. :-) > There was an open question about what to do if a use-case came along > where we needed to pass additional parameters to > kvm_arch_gmem_invalidate() other than just the start/end PFN range for > the pages being freed, but we'd determined that SNP and TDX did not > currently need this, so I didn't have any changes planned in this > regard. > > If we now have such a need, what we had proposed was to modify > __filemap_remove_folio()/page_cache_delete() to defer setting > folio->mapping to NULL so that we could still access it in > kvm_gmem_free_folio() so that we can still access mapping->i_private_list > to get the list of gmem/KVM instances and pass them on via > kvm_arch_gmem_invalidate(). Yeah, this is what I was remembering. I obviously forgot that we didn't have a need to iterate over all bindings at this time. > So that's doable, but it's not clear from this discussion that that's > needed. Same here. And even if it is needed, it's not your problem to solve. The above blurb about needing to preserve folio->mapping being free_folio() is sufficient to get the ARM code moving in the right direction. Thanks! > If the idea to block/kill the guest if VMM tries to hole-punch, > and ARM CCA already has plans to wire up the shared/private flags in > kvm_unmap_gfn_range(), wouldn't that have all the information needed to > kill that guest? At that point, kvm_gmem_free_folio() can handle > additional per-page cleanup (with additional gmem/KVM info plumbed in > if necessary).