From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751887AbdKZAV0 (ORCPT ); Sat, 25 Nov 2017 19:21:26 -0500 Received: from mail.kernel.org ([198.145.29.99]:56342 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751719AbdKZAVY (ORCPT ); Sat, 25 Nov 2017 19:21:24 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 414B6219C1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: AGs4zMZfXHrdSPLhgaHIl4sR48fy5dy2JIXxKQgY9LQt8xsmYIW3smgnU6FX+wBvFP8chOhWHpuS26yP4k1g731ALUM= MIME-Version: 1.0 In-Reply-To: References: <20171124172411.19476-1-mingo@kernel.org> <20171124172411.19476-43-mingo@kernel.org> <47186975-1DCB-4767-8C4C-0816931E3595@amacapital.net> From: Andy Lutomirski Date: Sat, 25 Nov 2017 16:21:03 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 42/43] x86/mm/kaiser: Allow KAISER to be enabled/disabled at runtime To: Thomas Gleixner Cc: Ingo Molnar , "linux-kernel@vger.kernel.org" , Dave Hansen , "H . Peter Anvin" , Peter Zijlstra , Borislav Petkov , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 25, 2017 at 2:48 PM, Thomas Gleixner wrote: > On Sat, 25 Nov 2017, Andy Lutomirski wrote: >> > On Nov 25, 2017, at 1:05 PM, Thomas Gleixner wrote: >> > On Sat, 25 Nov 2017, Andy Lutomirski wrote: >> >> Keep in mind that, for a static_branch, actually setting the thing needs >> >> to be deferred, but that's straightforward. >> > >> > That's not an issue during boot. That would be an issue for a run time >> > switch. >> >> What I mean is: if you modify a static_branch too early, it blows up terribly. > > I'm aware of that. We can't switch it in the early boot stage. But that > does not matter as we can switch way before we reach user space. > > The early kaiser mappings are fine whether we use them later or not. At the > point in boot where we actually make the decision, there is nothing more > than the extra 4k shadow which got initialized. > > If we ever want to do runtime switching, then the full shadow mapping needs > to be maintained even while kaiser is disabled, just the NX poisoning of > the user space mappings is what makes the difference. One unfortunate thing is that, if we boot with kaiser off and don't intend to ever switch it on at runtime, we could avoid the 8k pgd allocations. But if we want to be able to enable kaiser, we need the 8k mappings. My inclination is to not try for runtime control until some distro asks for it. In general, I think that trying to runtime switch without stop_machine is a bit nuts, and getting it to be reliable even with stop_machine is gross. Not to mention that stop_machine is currently incompatible with writing to static branches, although that's fixable. --Andy