[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aWrHAeMcjDpVnTBp@google.com>
Date: Fri, 16 Jan 2026 15:17:21 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Rick Edgecombe <rick.p.edgecombe@...el.com>
Cc: bp@...en8.de, chao.gao@...el.com, dave.hansen@...el.com,
isaku.yamahata@...el.com, kai.huang@...el.com, kas@...nel.org,
kvm@...r.kernel.org, linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org,
mingo@...hat.com, pbonzini@...hat.com, tglx@...utronix.de,
vannapurve@...gle.com, x86@...nel.org, yan.y.zhao@...el.com,
xiaoyao.li@...el.com, binbin.wu@...el.com,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH v4 07/16] x86/virt/tdx: Add tdx_alloc/free_page() helpers
On Thu, Nov 20, 2025, Rick Edgecombe wrote:
> +/*
> + * Return a page that can be used as TDX private memory
> + * and obtain TDX protections.
Wrap at ~80.
This comment is also misleading, arguably wrong. Because from KVM's perspective,
these APIs are _never_ used to back TDX private memory. They are used only for
control pages, which yeah, I suppose might be encrypted with the guest's private
key, but most readers will interpret "used as TDX private memory" to mean that
these are _the_ source of pages for guest private memory.
> + */
> +struct page *tdx_alloc_page(void)
And in a similar vein, given terminology in other places, maybe call these
tdx_{alloc,free}_control_page()?
> +{
> + struct page *page;
> +
> + page = alloc_page(GFP_KERNEL);
GFP_KERNEL_ACCOUNT, all of these allocations are tied to a VM.
> + if (!page)
> + return NULL;
> +
> + if (tdx_pamt_get(page)) {
> + __free_page(page);
> + return NULL;
> + }
> +
> + return page;
> +}
> +EXPORT_SYMBOL_GPL(tdx_alloc_page);
Note, these can all now be EXPORT_SYMBOL_FOR_KVM.
Powered by blists - more mailing lists