linux-kernel - Comments on UV tlb flushing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <488E644B.10801@goop.org>
Date:	Mon, 28 Jul 2008 17:28:59 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Cliff Wickman <cpw@....com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Comments on UV tlb flushing

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/