Received: by 10.223.164.202 with SMTP id h10csp2615373wrb; Mon, 27 Nov 2017 21:19:18 -0800 (PST) X-Google-Smtp-Source: AGs4zMZCYbb31PE9Zvz99U7JbzCB0ldG8oaMDM14L1O1EERi/mf2sMiJq+pzWndVrekFzGrKDChW X-Received: by 10.99.112.92 with SMTP id a28mr40356579pgn.413.1511846358706; Mon, 27 Nov 2017 21:19:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511846358; cv=none; d=google.com; s=arc-20160816; b=qsAsCXmJcXc8B7cNGt4Xseos0biVgnPBlCVgxpbb5jGk1mEgrZgZPlR5RGQKjaXpmh kBpEKT+TjpM4MZ/8Mk+VFtR8IdISPYEHJgVU/5HT0Q/ia8K9l51yTzYQy/yeZ7j6wRx1 cwu9YtReqFlIL235YCe7UU/xBu388bJ4L0oATZarB4LBc1AbMzvE1yTK3cEwZZ4fA4Yx TtnUWbH8XMGnHyeYj+5HDcJiiebeHSndL8c8HFtGUXR0qAPMrFPCvR4+wOs+Nn7Zpf5K 8+FjKRa7UVfnyBXiVZxA7vVNhfpYsTz1Oi/SPO7gQUTYlfZBqN5djV7vCdw7CMlWWaIj kL3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=tL7QcF5gJHsmMFUL1v5sxH4FtuEEaZK+DD7NM3bR8zI=; b=afiXzmYgWcdXv4/G135X/e8oucSbG+tAbVMrwwU6kDWhPuMIycKgyPlUyPt5eEVLwh Uqz+C4UyYF6sVE2sw3tnNx7OBYPrQM+dThOi60xyivlCf4zPFx+7GVqEc5ZSKOilxV3r wZTh+U/xrFWG6Y8x/zkwhBEHoZtDS3w6TKxTqeTfLtDBGCQ+9ZQ45FHI1Gn7NHZ6xC/K igyijewH3T5WxEYlZnMlE3mzS9ehD9BVyyuC6FBA5pvfGgF/MpG2wI9xf2nYPTv9srPG QXo1jnXeLxiKwid1MA/kL8z156M7v4VaHVto6Xs4B1Y27SFc5JTGVcrti/hQQBJnB9uS ogSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=hEcolMN2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m32si561691pld.667.2017.11.27.21.18.58; Mon, 27 Nov 2017 21:19:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=hEcolMN2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751036AbdK1FQm (ORCPT + 77 others); Tue, 28 Nov 2017 00:16:42 -0500 Received: from mail-io0-f194.google.com ([209.85.223.194]:39486 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750796AbdK1FQl (ORCPT ); Tue, 28 Nov 2017 00:16:41 -0500 Received: by mail-io0-f194.google.com with SMTP id x63so38929885ioe.6 for ; Mon, 27 Nov 2017 21:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tL7QcF5gJHsmMFUL1v5sxH4FtuEEaZK+DD7NM3bR8zI=; b=hEcolMN2yE7+xqoDl53hmz4LTck7R1EDNm8uDj8bb625Ie0rDdcMXg6yc72DIzLDDx lhHNzsOf4UxNtATewds3pdGs4EqtdGvbMoT/sTmOWnQCm/j3FboT2pT0PaYgP+mIZQgE /n3z6RZYZFXRCTmUyJ7G8pTdmbL+TslKgvBfRi8npmuJ70ieyKc59O4LxPLIsg6OEqPn 4fSIOnLdgozH3d9VC3rP+POixnlcTHFnGzCWd+/PNlcBJ8rbqp3cHaveoViYk4euL1zS lF+FW64J6nmKZD8O4SVJBePn5uXQW+iDQUSEjz68DIY1n8IDVHGZwnrxoVUJ+mZCJCL+ c4oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tL7QcF5gJHsmMFUL1v5sxH4FtuEEaZK+DD7NM3bR8zI=; b=jo6iYsgBMzJc0riSwXPb7OqdZtvX8ORycv988UzexS/9G/rG+m+dKAHHIGrl6mh+hF +CISbnriZnJ6A3JUN//LrGDvyt9LEMPt6coCXUGlKHhpFp7mCXCqsehkOOWsnSUS2kGe 3uu0hh1qtdXOWN+TULuTFZl5fGSufLU1cfZGsUbFZU6SWh30r4FQrwRkzqglqrSLLEWO AfgJ2gQxFfXIMG2dv8zJ/Cr/uZd73Bfzfr4wXcEuddXUBC1Sdp7rIwHzeeP52Jd6LOnf YceBLDlQFKnFto14wWEM+uDKIEBUVmuXcAilrbCB6GneRtKPGyE4OVwQ62CvVvgflGfc izfQ== X-Gm-Message-State: AJaThX4gP/8L4IdTmT0qw5E34c2c/OmrpNZJKLTjY5kHSHP6cdXDKH7p TTJs8Qsw8r9vYE3bMAuj8oi9ry6u5gD32hq3lKcIIA== X-Received: by 10.107.102.18 with SMTP id a18mr47580194ioc.105.1511846200167; Mon, 27 Nov 2017 21:16:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.133.35 with HTTP; Mon, 27 Nov 2017 21:16:19 -0800 (PST) In-Reply-To: <20171127104923.14378-16-mingo@kernel.org> References: <20171127104923.14378-1-mingo@kernel.org> <20171127104923.14378-16-mingo@kernel.org> From: Andy Lutomirski Date: Mon, 27 Nov 2017 21:16:19 -0800 Message-ID: Subject: Re: [PATCH 15/24] x86/mm: Allow flushing for future ASID switches To: Ingo Molnar Cc: "linux-kernel@vger.kernel.org" , Dave Hansen , Thomas Gleixner , "H . Peter Anvin" , Peter Zijlstra , Borislav Petkov , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 27, 2017 at 2:49 AM, Ingo Molnar wrote: > From: Dave Hansen > > If changing the page tables in such a way that an invalidation of > all contexts (aka. PCIDs / ASIDs) is required, they can be > actively invalidated by: > > 1. INVPCID for each PCID (works for single pages too). > > 2. Load CR3 with each PCID without the NOFLUSH bit set > > 3. Load CR3 with the NOFLUSH bit set for each and do INVLPG for each address. > > But, none of these are really feasible since there are ~6 ASIDs (12 with > KAISER) at the time that invalidation is required. Instead of > actively invalidating them, invalidate the *current* context and > also mark the cpu_tlbstate _quickly_ to indicate future invalidation > to be required. > > At the next context-switch, look for this indicator > ('all_other_ctxs_invalid' being set) invalidate all of the > cpu_tlbstate.ctxs[] entries. > > This ensures that any future context switches will do a full flush > of the TLB, picking up the previous changes. NAK. We need to split up __flush_tlb_one() into __flush_tlb_one() and __flush_tlb_one_kernel(). We've gotten away with having a single function for both this long because we've never had PCID on and nonglobal kernel mappings around. So we're busted starting with "x86/mm/kaiser: Disable global pages by default with KAISER", which means that we have a potential corruption issue affecting anyone who tries to bisect the series. Then we need to make the kernel variant do something sane (presumably just call __flush_tlb_all if we have PCID && !PGE). And, for the user variant, we need a straightforward, clean, efficient way to mark a given address space on a given CPU as needing a usermode PCID flush when its usermode tables are next loaded. This patch isn't it. --Andy From 1585216393710549190@xxx Mon Nov 27 10:56:00 +0000 2017 X-GM-THRID: 1585216393710549190 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread