On 25/05/2022 12:14, Jan Beulich wrote: > On 25.05.2022 12:52, Andrew Cooper wrote: >> On 25/05/2022 09:13, Roger Pau Monne wrote: >>> Rename the flag to better note that it's not actually forcing any IPIs >>> to be issued if none is required, but merely avoiding the usage of TLB >>> flush assistance (which itself can avoid the sending of IPIs to remote >>> processors). >>> >>> No functional change expected. >>> >>> Requested-by: Jan Beulich <[email protected]> >>> Signed-off-by: Roger Pau Monné <[email protected]> >>> --- >>> Changes since v2: >>> - New in this version. >> :( This needs reverting. >> >> It is specific to IPIs, because of our current choice of algorithm for >> freeing pagetables. >> >> "no assist" excludes ipi-helper hypercalls which invoke >> INVALIDATE_TLB_VECTOR. Such hypercalls do exist and specifically would >> be improvement that we ought to use. >> >> Furthermore, we do want to work around the limitation that created >> FLUSH_FORCE_IPI, because we absolutely do want to be able to use >> hypercalls/remote TLB flushing capabilities when available. >> >> I accept that FORCE_IPI perhaps isn't a perfect name, but it's a whole >> lot less bad than NO_ASSIST. > But FORCE_IPI has caused actual confusion while reviewing patch 2. > If NO_ASSIST doesn't suit you and FORCE_IPI is also wrong, can you > suggest a better name fitting both aspects?
I don't actually agree that FORCE_IPI is unclear to begin with. The safety property required is "if you need to contact a remote CPU, it must be by IPI to interlock with Xen's #PF handler". FORCE_IPI is very close to meaning this. If anything else is unclear, it can be clarified in the adjacent comment. ~Andrew
