On Wed, May 25, 2022 at 10:52:48AM +0000, 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.
So the improvement of that mechanism is that you can pass a cpumask parameter to an hypercall in order to avoid having to issue repeated wrmsrs (or APIC MMIO accesses) to send IPIs to different vCPUs? But that could be seen as generic assistance for triggering the execution of remote IDT handlers, and as such won't be restricted by the NO_ASSIST flag (also because it would be implemented in send_IPI_mask() rather than flush_area_mask() IMO). > 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 agree, we need to get rid of FLUSH_FORCE_IPI. > I accept that FORCE_IPI perhaps isn't a perfect name, but it's a whole > lot less bad than NO_ASSIST. I'm happy for you and Jan to decide on a different name that you both agree. Thanks, Roger.
