linux-kernel - Re: [PATCH v5 2/4] KVM: X86: Add paravirt remote TLB flush

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171116090757.2lgjdrzdclppiiwm@hirez.programming.kicks-ass.net>
Date:   Thu, 16 Nov 2017 10:07:57 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Wanpeng Li <kernellwp@...il.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kvm <kvm@...r.kernel.org>, Paolo Bonzini <pbonzini@...hat.com>,
        Radim Kr??m???? <rkrcmar@...hat.com>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH v5 2/4] KVM: X86: Add paravirt remote TLB flush

On Thu, Nov 16, 2017 at 04:51:39PM +0800, Wanpeng Li wrote:
> 2017-11-16 16:38 GMT+08:00 Peter Zijlstra <peterz@...radead.org>:
> > On Thu, Nov 16, 2017 at 01:30:57PM +0800, Wanpeng Li wrote:
> >> -static DEFINE_PER_CPU(cpumask_var_t, __pv_tlb_mask);
> >> +static DEFINE_PER_CPU(cpumask_t, __pv_tlb_mask);
> >
> > NR_CPUS=512 is a fairly common distro setting, that means cpumask_t is
> > 64 bytes. So for my 144 CPU system, that is 9216 bytes I'll never see
> > again.
> >
> > Not nice :/
> 
> Refer to "DECLARE_PER_CPU_SHARED_ALIGNED(cpumask_t, cpu_sibling_map)"
> in arch/ia64/include/asm/smp.h, it also defines variable directly,
> however, some other archs are not. kvmclock_init() is also called very
> early during boot, it utilizes memblock to alloc some memory.

So the difference is that the sibling map is guaranteed to be used.

This map of yours is only ever used if you run a paravirt kernel on a
new enough host to advertise the capability etc.

As said on IRC; I'm forever lost in the whole init / paravirt setup
maze, but can't you simply do things later when the allocators work?
ISTR we don't in fact run the alternative stuff _that_ early anyway.