Re: [PATCH 1/2] x86/virt/tdx: Drop tdx_clflush_*()

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

On Wed, 2026-09-23 at 14:58 +0300, Nikolay Borisov wrote:
> The code change itself is trivial, however nothing in the code being 
> removed is tied to CLFLUSH_BEFORE_ALLOC directly. And from the changelog 
> it's not entirely clear which those operations are (as per other 
> reviewers feedback). Looking at the TDX module spec that flag is 
> mentioned in relation to the following 3 operations:
> 
> TDH.MEM.SEPT.ADD
> TDH.MEM.PAGE.ADD
> TDH.MEM.PAGE.AUG
> 
> Whereas the patch also removes flushing from MNG_CREATE/VP_ADDCX/MNG_ADDCX

The docs are a bit too ambiguous for my preference, but in the "ABI spec" it has
this blurb:
   When allocating a memory page to be used as TD private memory or TD control
   structure page, the host VMM is required to ensure that none of the cache
   lines associated with the page is in a MODIFIED state.

So those others should be covered by "TD control structures". It would have been
nice if these bits were included in the base spec flows too. But I think it's a
symptom of that this arch was never really needed.

Similarly, for the system scoped memory that can have reclaim, I would have
expected that the HW limitation reasoning would be the same as the TD scoped
memory. But the docs are even less clear on that point. So the docs were never
super clear on how this should work in general.

Instead we have the original intention of the Linux code, and some recent
promises from TDX arch folks:
 - CLFLUSH_BEFORE_ALLOC will not be set in the future
 - VMM is not required to call TDH.PHYMEM.PAGE.WBIND on page reclaim on any 
   platforms supporting TDX.

Does it seem sufficient?

> 
> 
> So concrete references in the changelog would be much appreciated i.e 
> whether flushing for those 3 additional functions was because people 
> were overzealous, or they simply have been omitted from the public 
> documentation.

I'll try to add something to the effect of the above, if it explains it enough.