Re: [PATCH v3 00/24] KVM: TDX huge page support for private memory

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Wed, 2026-01-14 at 16:19 -0800, Sean Christopherson wrote:
> I've no objection if e.g. tdh_mem_page_aug() wants to sanity check
> that a PFN is backed by a struct page with a valid refcount, it's
> code like that above that I don't want.

Dave wants safety for the TDX pages getting handed to the module. Sean
doesn’t want TDX code to have specialness about requiring struct page.
I think they are not too much at odds actually. Here are two ideas to
get both:

1. Have the TDX module do the checking

Yan points out that we could possibly rely on
TDX_OPERAND_ADDR_RANGE_ERROR to detect operating on the wrong type of
memory. We would have to make sure this will check everything we need
going forward.

2. Invent a new tdx_page_t type.

We could have a mk_foo()-type helpers that does the checks and converts
kvm_pfn_t to TDX’s verified type. The helper can do the checks that it
is valid TDX capable memory. Then there is one place that does the
conversion. It will be easy to change the verification method if we
ever need to.

One benefit is that struct page has already been a problem for other
reasons [0]. To work around that issue we had to keep duplicate formats
of the TDVPR page and lose the standardization of how we handle pages
in the TDX code. This is perfectly functional, but a bit annoying.

But (2) is inventing a new type, which is somewhat disagreeable too.
 
I’m thinking maybe explore 1 first, with the eventual goal of moving
everything to some type of pfn type to unify with the rest of KVM.
Either KVM’s or the normal one.  But before we do that, can we settle
on what sanity checks we want:
1. Page is TDX capable memory
2. ... I think that is it? There was some discussion of refcount
checking. I think we don’t need it?

[0]
https://lore.kernel.org/kvm/20250910144453.1389652-1-dave.hansen@linux.intel.com/#r