Comments on UV tlb flushing

[Jeremy Fitzhardinge <jeremy@goop.org>]

I'm just reworking the x86 tlb code to use smp_call_function_mask, and I 
see how the UV tlb flushing hooks in.  A few things occur to me:

   1. There should be a CONFIG_X86_UV to select this code.  tlb_uv.o is
      around 6k, which is not trivial overhead to subject every x86_64
      kernel to.
   2. CONFIG_X86_UV should either depend on or select CONFIG_PARAVIRT.
   3. You should hook into paravirt_ops to enable your tlb-flush code. 
      That is, in - say - uv_bau_init() you do
      "pv_mmu_ops.flush_tlb_others = uv_flush_tlb_others".  This removes
      a test/branch in the generic code.  Using paravirt_ops may open
      other opportunities to put UV-optimised functions in place without
      having to modify generic code.

My understanding is that the UV hardware has some kind of 
payload-carrying IPI mechanism, which is a capability could be useful to 
express in a higher-level way in the kernel.  Certainly I could imagine 
using it in a virtual environment as a way to do inter-VCPU messaging 
with less context switch overhead.

Thanks,
    J