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