From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B66EC43461 for ; Fri, 11 Sep 2020 00:33:42 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 347A8208FE for ; Fri, 11 Sep 2020 00:33:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="f/l3ZWLy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 347A8208FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kGWzz-00025Y-ON; Fri, 11 Sep 2020 00:33:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kGWzy-00025T-Si for xen-devel@lists.xen.org; Fri, 11 Sep 2020 00:33:07 +0000 X-Inumbo-ID: 197e7add-e1eb-4e21-9ddb-ee2a49840858 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 197e7add-e1eb-4e21-9ddb-ee2a49840858; Fri, 11 Sep 2020 00:33:05 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A237F208FE; Fri, 11 Sep 2020 00:33:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599784385; bh=pOom+B5I2E72/Z01rFwFdXMdIj3bOGjqy1POd1IkJJY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=f/l3ZWLyt0vyyUyUA7MmbS++4F7wLKFmDe1/Kk737RATi3R4QJt/ICN03X40Pkz6U G4DoQ7/O9S9ZH6buQGujpI5cvKqnJnyg68QJUmSvdIL+6ttOc9LrnTkkhPKq+mzuM0 4mre9kHah1b7guowYxj33tJp8ZJGzmDzstm40gqk= Date: Thu, 10 Sep 2020 17:33:04 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Jan Beulich cc: Bertrand Marquis , "xen-devel@lists.xen.org" , Julien Grall , Stefano Stabellini , George Dunlap , jgross@suse.com Subject: Re: Runstate hypercall and Linux KPTI issues In-Reply-To: Message-ID: References: <1844689F-814F-48AE-8179-95B0EE4E734C@arm.com> <8b9d8bc8-254e-01db-6ba3-ec41bc9cd2c7@suse.com> <2AD6A14F-AA25-464D-9E9E-6067F2F43F29@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 10 Sep 2020, Jan Beulich wrote: > >>> - should we backport the support for this hypercall in older kernel releases ? > >> > >> It's a bug fix to KPTI, and as such ought to be at least eligible for > >> considering doing so? > > > > That will mean also backport in Linux. What should be the scope ? > > All longterm and stable trees which are affected, as I think is usual. >From a Linux perspective, we should fix this as soon as possible: we should backport a patch to make the usage of the runstate hypercall conditional on KPTI being disabled on ARM. Then, when available in Xen, we should backport the usage of the new hypercall with a check to detect if it is available -- do not assume it is available, users might not update Xen, but might update Linux. We have to do this in two stages for a couple of reasons. It is best not to wait for Xen-side changes to fix Linux any longer. And also, a Linux fix is best implemented independently anyway: Linux should benefit from the Xen improvements when available but not rely on their presence to work.