On Wed, May 25, 2022 at 09:34:32AM +0200, Jan Beulich wrote: > On 25.05.2022 09:21, Roger Pau Monné wrote: > > On Wed, May 25, 2022 at 08:02:17AM +0200, Jan Beulich wrote: > >> On 24.05.2022 18:46, Roger Pau Monné wrote: > >>> Would you be fine with adding: > >>> > >>> Note that FLUSH_FORCE_IPI doesn't need to be handled explicitly, as > >>> it's main purpose is to prevent the usage of the hypervisor assisted > >>> flush if available, not to force the sending of an IPI even for cases > >>> where it won't be sent. > >> > >> Hmm, yes, that's even more verbose than I would have expected it to > >> be. Just one point: I'm not sure about "main" there. Is there really > >> another purpose? > > > > Right, I should remove main. > > > >> Of course an alternative would be to rename the flag to properly > >> express what it's for (e.g. FLUSH_NO_HV_ASSIST). This would then > >> eliminate the need for a comment, afaic at least. > > > > I think it's likely that we also require this flag if we make use of > > hardware assisted flushes in the future, and hence it would better > > stay with the current name to avoid renaming in the future. > > > > Whether the avoidance of sending the IPI is due to hardware or > > hypervisor assistance is of no interest to the caller, it only cares > > to force a real IPI to be sent to remote processors. > > Well, then it could still be named FLUSH_NO_ASSIST, since as said > (and as you look to agree with) there's no IPI being forced in the > general case.
That would be fine but I don't think it's OK to do in this patch. Could do as a prereq if you want, but we should keep in mind the patch under discussion is fixing a boot regression, the fact that it doesn't trigger in osstest is just because there's no hardware with CET Shadow Stacks support in the colo. Thanks, Roger.
