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

[Nikolay Borisov]

On 23.09.26 г. 19:26 ч., Edgecombe, Rick P wrote:
> 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?

In my opinion the above contains important historical detail and it 
would be good that it's not lost so putting it, probably slightly 
rephrased and/or summarised in the changelog will be beneficial.

> > 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.

Works for me, thanks!