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 72746262D0B for ; Mon, 29 Jun 2026 22:02:33 +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=1782770554; cv=none; b=UqxlamOER0DE6OdYDZlnVucsSRf3r5AJWntR70N0LPG1W7L9+QQs6GXdL276A0S8/cE9DDAy+sGFICyrSCoOgrz34mjWL2aLy31OXoUh9r1TBiXhxYviF8/1Z6hfO+6MBgL4ZMKtxXj05JByUmUHxW+IN9w1sKOmzQO3cOMzBa8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782770554; c=relaxed/simple; bh=T1ui5rQxsJ4ZDgmKCTatJkmDZuhRypTinUX72gLehS8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=pwX+n/YYtW7wtbOeutgPJKHqjfkF6OZ0bM7OEf4l79fm8MlM9/0dnF3hzcqT97ean6mys2hx5EiYFkkSqYZ7U2pd8LXs9lNW5qETbfSY+CE36rxuTqBlzJqja/msO+9U2CIImUe3moiYWyiaplgFHq5bDM/Jd5zXRropP1ey74U= 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=ORESLJxP; 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="ORESLJxP" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-37fbdbc4d03so1901066a91.1 for ; Mon, 29 Jun 2026 15:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782770553; x=1783375353; darn=vger.kernel.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=HMo112Q1QX2gMdVrOPPjVAkdlX7RfH+smaOCRiFcEdc=; b=ORESLJxPmHIoAiPDZYuoARyPWkL6a75ViKPBqHQPSfwB6W6erjuyin/u2fJS67/IMX vr3j7d87aZWuNmjtto/KXSqQvynBz9EThTUi+xI9FuRbrdMZN0mVVnzgnbFbpmN9IYeV WbFiz7xlhMP4B5NwjT3V7/rok9sb/Ky+IIzJptQ6ihrYu2J5SiPFc2+bjYp0ANr8CPkm K6Wnl8vfISvzw2HRqDuRcuLrh/J5j66gZHaUKQw+OvF6nRnZWwV0WJOmBmrMS/i/3x7q szkzzCpLDsuOlzmo2JSqn4JpaU6OSW84TbGaLBImJy9swf7GxbLWCXr1XG6b5KgcNLcn 4BKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782770553; x=1783375353; 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=HMo112Q1QX2gMdVrOPPjVAkdlX7RfH+smaOCRiFcEdc=; b=GvxDeLKlqpjRqCFRPchQueeREiLNO8VFLQBgpaUkB1Pc/O6+su7Rro0ZlQI4a5XMQZ 5mJ9Hrak3wBtPBoG4jWsGx46zr/HE58CLeFGn7PueaO8HEDa2F64T98E7NqWzwzU8kq1 qCAZiIzXJ7+7/TnX0UKcYr8GwaogHpSgm12yQ+CoYTs0Ifby1oArnig2EWrlal2FQnIf FFlgDCmkpIBqk7xL4RxrlNqkl9yYJpEZ/TBksKU5LbnyD0ZI5UWpley4XEYucmEmRu54 M4QWIQSGqKWcGZEoXgr2J90jXwmVTnMEAjIwKobBMEF6DnVaqgnrCkoBC3Usakb6h1G+ nrnQ== X-Forwarded-Encrypted: i=1; AHgh+RqTaMNbnWlKJuAUu5qpFEeww92EEK3uE7vIx0x4pwOYZj9ENhYGliMkLlNLLKL7kCBP6iAGAfuzw09Uh4U=@vger.kernel.org X-Gm-Message-State: AOJu0YyQgp8SvlFDp5l6kmauIsoJjPLoL2i7u9JxyBKNmdXlyf9by3hY AfNSxflG7cM2OTJtwntXxk3z7RC8oGwbx8uX61uhX3WYw3SUqCvJ6IsPMluKmuy5oGo12+A2yId LVBYvBw== X-Received: from pjdx1.prod.google.com ([2002:a17:90a:bc1:b0:36b:dbd1:f512]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5447:b0:37f:d265:18d2 with SMTP id 98e67ed59e1d1-3805337b000mr526877a91.7.1782770552384; Mon, 29 Jun 2026 15:02:32 -0700 (PDT) Date: Mon, 29 Jun 2026 15:02:31 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260626231416.3943216-1-seanjc@google.com> <20260626231416.3943216-5-seanjc@google.com> Message-ID: Subject: Re: [PATCH v2 4/9] KVM: Rework .gmem_invalidate() into .gmem_free_folio() From: Sean Christopherson To: Ackerley Tng Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Hyunwoo Kim , Tom Lendacky , Michael Roth , "=?utf-8?B?SsO2cmcgUsO2ZGVs?=" , Fuad Tabba Content-Type: text/plain; charset="us-ascii" On Mon, Jun 29, 2026, Ackerley Tng wrote: > Sean Christopherson writes: > > > > > [...snip...] > > > > > > -void sev_gmem_invalidate(kvm_pfn_t start, kvm_pfn_t end) > > +void sev_gmem_free_folio(struct folio *folio) > > { > > + kvm_pfn_t start = page_to_pfn(folio_page(folio, 0)); > > + kvm_pfn_t end = start + (1ul << folio_order(folio)); > > kvm_pfn_t pfn; > > > > if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP)) > > I thought we intended to draw the line such that the platforms don't > reference folios, and so this function should be parametrized by pfn. > > I think we should still stick with > > .free_folio = kvm_gmem_free_folio > > and kvm_gmem_free_folio() translates the folio to pfns and calls the > arch function, named something like .gmem_LIFECYCLE_ACTION_pfn_range. > > Now for LIFECYCLE_ACTION, one way to think of it is that this should > represent the point in the lifecycle of guest_memfd memory where the > memory is removed from guest's private use, so perhaps "host_reclaim"? kvm_arch_gmem_reclaim_memory()? I don't want to include "host", because the "reclaim" may or may not be host initiated. I don't want to use "pfn_range" because it's too close to "gfn_range". > Then kvm_gmem_free_folio() becomes: > > kvm_gmem_free_folio() { > pfn_start, pfn_end = translate folio to pfn range; > kvm_x86_call(gmem_host_reclaim_pfn_range)(pfn_start, pfn_end); > } > > > And in conversions > > if (!to_private) { > pfn_start, pfn_end = translate guest_memfd offset range to pfns; > kvm_x86_call(gmem_host_reclaim_pfn_range)(pfn_start, pfn_end); > } > > (and now it is right for the !to_private check to remain in guest_memfd > since we're explicitly using that to guard a *host* reclaim function. > > Another way to think of LIFECYCLE_ACTION is to have the hook represent > the point of time where the memory's attribute is being set. Perhaps > "set_attributes"? > > Then kvm_gmem_free_folio() becomes: > > kvm_gmem_free_folio() { > pfn_start, pfn_end = translate folio to pfn range; > kvm_x86_call(gmem_set_attributes_pfn_range)(pfn_start, pfn_end, SHARED); No, because this isn't about setting memory PRIVATE vs. SHARED, it's about freeing memory back to the host. Which is why I suggested the comically verbose CONFIG_KVM_ARCH_GMEM_FREE_ON_SHARED_CONVERSION: SEV-SNP effectively frees memory when converting to shared. > } > > because when freeing a folio we want to set the attributes to SHARED. No, because the RMP isn't being moved to a "shared" state per se, rather the page is being unassigned. And from KVM's perspective, freeing the folio can happen even if the memory isn't first converted to SHARED (in KVM's memory attributes). > And in conversions > > if (kvm_x86_call(gmem_should_set_attributes_pfn_range)(SHARED)) { > pfn_start, pfn_end = translate guest_memfd offset range to pfns; > kvm_x86_call(gmem_set_attributes_pfn_range)(pfn_start, pfn_end, SHARED); > } > > This is biased towards conversions (related proposal at [1]). > > [1] https://lore.kernel.org/all/CAEvNRgGX3GkazCWM=6y9YLgn=YemXuG==Oo+L58cac1Fd86_TQ@mail.gmail.com/ > > > > > [...snip...] > >