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

[Nikolay Borisov <nik.borisov@suse.com>]

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!