Re: [PATCH v4 3/7] x86/virt/tdx: Mark memory cache state incoherent when making SEAMCALL

[Chao Gao]

>> And tracking cache incoherent state at the per-CPU level seems to add
>> unnecessary complexity. It requires a new do_seamcall() wrapper, setting the
>> flag on every seamcall rather than just the first one (I'm not concerned about
>> performance; it just feels silly), and using preempt_disable()/enable(). In my
>> view, per-CPU tracking at most saves a WBINVD on a CPU that never runs
>> SEAMCALLs during KEXEC, which is quite marginal. Did I miss any other benefits?
>
>The cache state is percpu thus a percpu boolean is a natural fit.  Besides
>the benefit you mentioned, it fits better if there are other cases which
>could also lead to an incoherent state:
>
>https://lore.kernel.org/lkml/eb2e3b02-cf5e-4848-8f1d-9f3af8f9c96b@xxxxxxxxx/
>
>Setting the boolean in the SEAMCALL common code makes the logic quite
>simple:
>
>  If you ever do a SEAMCALL, mark the cache in incoherent state.
>
>Please see Dave's comment here:
>
>https://lore.kernel.org/lkml/31e17bc8-2e9e-4e93-a912-3d54826e59d0@xxxxxxxxx/
>
>The new code around the common SEAMCALL is pretty marginal comparing to
>the SEAMCALL itself (as you said), and it's pretty straightforward, i.e.,
>logically less error prone IMHO, so I am not seeing it silly.

Sure, let's follow Dave's suggestion.

For anyone else who has the same question, see the discussion here:

https://lore.kernel.org/lkml/9a9380b55e1d01c650456e56be0949b531d88af5.camel@xxxxxxxxx/
https://lore.kernel.org/lkml/6536c0cf614101eda89b3fe861f95ad0c1476cfd.camel@xxxxxxxxx/

Both options, per-CPU variable and global variable, were evaluated, and the
agreed approach is to use the per-CPU variable. Apologize for the noise.