From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E231B6DD1F for ; Fri, 9 Feb 2024 15:13:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707491597; cv=none; b=YTQjFiURgvRFQXIBu7ANit4LG5RGGxrAkv5v/FBQnSM9a3siQzXboozan3vyfqxd7Tj4W6K/Ek3oIgaG37SaTA68cX+MUedLnzMzZQfnhVcEUo7lgbRutkdlKZl0kHZfphYKp5WGL8a2PmwJZ68XHp7IbkxrkHxRbXTbOpXE7ok= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707491597; c=relaxed/simple; bh=Bug3A6ZbFfpsIwrLaT1Ik2CEiJjUByjmzkWryqfXzuU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=qRNQMTPGV4L38cUu7PSg3Y52hDaPIGuiB+fAuLIjZjkmZxjna3zFNxVpSWc1QfrT6rKmSDuCRGxHhXrD6YNn2WCuqBXWXV/b3fLGa9ORw3xtpb0ueRu9pAARq6ZdeYIG7cK0JA/kAu54OxHG6gAWhfa0GdJEuRok3SGDIj+6vyY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=x7RkO/op; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="x7RkO/op" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-290c6d7776eso994204a91.2 for ; Fri, 09 Feb 2024 07:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707491595; x=1708096395; darn=lists.linux.dev; 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=x7RkO/opnzVcT/cG0LZHVLYLBVI0bKfj4MhMAGzZKZYrvmiYZGasgQ/YCirYOSU0k2 StQ0uTGj8gaJDBFMifw+GSCCjBqTidFWaPpWz0CA/AE4qXSKtMD8txpmapmTGCqSdfXY LuoQCqUzqLn0j5PM/8+aBxLOf00L/+3qD6isMuzcK6Xphz3A1iOIBu2BlVxiaMK65g/d JBPNvJfXrlBWyfTTKSZA3XJwzUeu2YdBoG+dOO70/ixr7vEynZv9y3T7Cm8+NEhDkmNT CzbO7OpgrZWjTklKX3uQrGWj7kag6zomv5cix2lt7Nbf2JGUM1ZdxynG5GScFmX+/h/M RboQ== 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=taY0SnmwKpJWF/7doBXSUVtb3eVfW1rcIC9Ywk69X5nLHxKgiz9E44D1Hjg8AqbBpY 7EyWlAlJhJLr4Qq/SoN7yUw1j+elXMo1Q5ZZFB9LxpnkOgYASSdIk7H57gMgIQN8Shrk d2Y3/M+lolM6A4ixbJIpZjBn1lLv+TrcGVO7Q8LBFXFvovC2i/nK8jTnsJWz17ppOLvl TYFO1GJ20RYq93KDro/QiSQY5qN4h0+Ym/PkuPVgpTF2zfc7DQ9N1/V8Kantrr+7SGri Mv7IW0PrV1qvrfc3Q+Q5coZe99x4Lfw3YwDYuk0IAJmhKUqeqXFFJmph0P9W4rX1aY1c s6rA== X-Forwarded-Encrypted: i=1; AJvYcCX3uZrftqwVc0jif/1Yhnk4foJuKelbUX71V8gJH0ECgqdu4CvFocYQsRhRtmg5MvVCF55ddyaIV4HFY+MhJxKs8Ce7drSqR2IGlQ== X-Gm-Message-State: AOJu0YxbxnaJtvZzpu8oXE6APGdkejhltRsxBWwkTPipF9B87J19Ro2Y vdMXN4vSOOzKvZ8p1JUkJ1Z9b2XMXkwbIXEWN189+/hqjh3PGZHZMhK6IgmdtnwzkjTio4AFnKF H9Q== 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> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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" 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