From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by kanga.kvack.org (Postfix) with ESMTP id 013D36B1B53 for ; Mon, 20 Aug 2018 18:36:04 -0400 (EDT) Received: by mail-pg1-f199.google.com with SMTP id h5-v6so6852155pgs.13 for ; Mon, 20 Aug 2018 15:36:03 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id r5-v6sor2494979pgn.106.2018.08.20.15.36.01 for (Google Transport Security); Mon, 20 Aug 2018 15:36:01 -0700 (PDT) Date: Mon, 20 Aug 2018 16:35:57 -0600 From: Tycho Andersen Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) Message-ID: <20180820223557.GC16961@cisco.cisco.com> References: <20180820212556.GC2230@char.us.oracle.com> <1534801939.10027.24.camel@amazon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: David Woodhouse , Konrad Rzeszutek Wilk , juerg.haefliger@hpe.com, deepa.srinivasan@oracle.com, Jim Mattson , Andrew Cooper , Linux Kernel Mailing List , Boris Ostrovsky , linux-mm , Thomas Gleixner , joao.m.martins@oracle.com, pradeep.vincent@oracle.com, Andi Kleen , Khalid Aziz , kanth.ghatraju@oracle.com, Liran Alon , Kees Cook , jsteckli@os.inf.tu-dresden.de, Kernel Hardening , chris.hyser@oracle.com, Tyler Hicks , John Haxby , Jon Masters On Mon, Aug 20, 2018 at 03:27:52PM -0700, Linus Torvalds wrote: > On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David wrote: > > > > It's the *kernel* we don't want being able to access those pages, > > because of the multitude of unfixable cache load gadgets. > > Ahh. > > I guess the proof is in the pudding. Did somebody try to forward-port > that patch set and see what the performance is like? > > It used to be just 500 LOC. Was that because they took horrible > shortcuts? Are the performance numbers for the 32-bit case that > already had the kmap() overhead? The last version I worked on was a bit before Meltdown was public: https://lkml.org/lkml/2017/9/7/445 The overhead was a lot, but Dave Hansen gave some ideas about how to speed things up in this thread: https://lkml.org/lkml/2017/9/20/828 Since meltdown hit, I haven't worked seriously on understand and implementing his suggestions, in part because it wasn't clear to me what pieces of the infrastructure we might be able to re-use. Someone who knows more about mm/ might be able to suggest an approach, though. Tycho