Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4037554pxb; Sun, 24 Oct 2021 18:11:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWoP3M2wGNN1ZtEDSbHAF6azi/r3P+FdXlx7D4POtOhYIa6YYpXQbyG4VLAm4F/qiT6u3c X-Received: by 2002:a17:90b:185:: with SMTP id t5mr17257603pjs.54.1635124277628; Sun, 24 Oct 2021 18:11:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635124277; cv=none; d=google.com; s=arc-20160816; b=IjHtMDGfAZjoc5+neg2sR1wbKbNZ6klQ0xL0kIrazOW4zARMBxvkk1dinJdJjots/c SScdJlO170ipe+8zsIaVC8VEhBxqnneV3cHvZpODm8oZYpUejBX0EJNPQBG1z1K8HF0x nJFO6OscXSR1OCaYaRDZMMglrf+0LVjzxDX8mT5jK1BehQnF0za8rpOOq1FDRGfFmugF cRWi2su9tpUemyY3L0MjdR/0p2HILMWEZA54PxfMYZHoTGPJmrglKFvtm6yV0JJ42TDH ffJGHNsvkEra1J53jOF0ErooSrWnxohWDinNLgObvJjkkNMdnFqwXgu6iJeq1Opf+04Z 9Gyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=rYn9Zm9aoPHhislAbYsNluKsg45kS9xvv0lJbzQatVM=; b=lfXvkkes584x4L24W/81Nkbf6wPKI1T63pn23qvklS4yuSEmdmrBDEjdpUBtQl+OJ4 B6UP1fpF0nKPTbPQik5AUzIhZ/yeRZntwpbWBuDlMl9THhSxrm2EaDhsEIOrHCPCt+40 AShhEefP0v6vgt5aq7OSiUnR2dQWB7PPb8q1YnIDjwcxPAxbAAKZlOTA7Qv+lARsZllr Q598E5NgRBtLg+QywIgWePwuTwQMpbCMk8/nHrjsMdeorqvDX6yIHM1E995qRlEKsOLE c3g3vgBUc6JjUoEMvQ7k6VcE4ee9XgSo2PiE6dDW0fry0AzRRDRcH26TwQKpdGh11KUL 40oQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hk6si16424779pjb.125.2021.10.24.18.11.03; Sun, 24 Oct 2021 18:11:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231725AbhJYAhT (ORCPT + 99 others); Sun, 24 Oct 2021 20:37:19 -0400 Received: from out30-42.freemail.mail.aliyun.com ([115.124.30.42]:40945 "EHLO out30-42.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229668AbhJYAhS (ORCPT ); Sun, 24 Oct 2021 20:37:18 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R651e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04357;MF=laijs@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0UtUKHVr_1635122094; Received: from C02XQCBJJG5H.local(mailfrom:laijs@linux.alibaba.com fp:SMTPD_---0UtUKHVr_1635122094) by smtp.aliyun-inc.com(127.0.0.1); Mon, 25 Oct 2021 08:34:55 +0800 Subject: Re: [PATCH V3 32/49] x86/entry: Add the C version ist_restore_cr3() To: Lai Jiangshan , linux-kernel@vger.kernel.org, Peter Zijlstra Cc: x86@kernel.org, Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" References: <20211014031413.14471-1-jiangshanlai@gmail.com> <20211014034121.17025-1-jiangshanlai@gmail.com> From: Lai Jiangshan Message-ID: <5591e2b1-5701-80da-557a-899fd3158697@linux.alibaba.com> Date: Mon, 25 Oct 2021 08:34:54 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211014034121.17025-1-jiangshanlai@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/10/14 11:41, Lai Jiangshan wrote: > > static __always_inline void switch_to_kernel_cr3(void) > { > if (static_cpu_has(X86_FEATURE_PTI)) > @@ -49,9 +70,34 @@ static __always_inline unsigned long ist_switch_to_kernel_cr3(void) > > return cr3; > } > + > +static __always_inline void ist_restore_cr3(unsigned long cr3) > +{ > + if (!static_cpu_has(X86_FEATURE_PTI)) > + return; > + > + if (unlikely(cr3 & PTI_USER_PGTABLE_MASK)) { > + pti_switch_to_user_cr3(cr3); > + return; > + } The C code is semantically copied from ASM. The ASM code is from the commit 21e9445911025("x86/mm: Optimize RESTORE_CR3") which still keeps the older behavior of writing to CR3 unconditionally even the saved CR3 is kernel CR3. Is there any special reason that the CR3 needs to be written for kernel CR3? I would add a commit to change it in ASM code by skipping cr3 write when it is kernel CR3, and then make the C code as the same as new ASM code. > + > + /* > + * KERNEL pages can always resume with NOFLUSH as we do > + * explicit flushes. > + */ > + if (static_cpu_has(X86_FEATURE_PCID)) > + cr3 |= X86_CR3_PCID_NOFLUSH; > + > + /* > + * The CR3 write could be avoided when not changing its value, > + * but would require a CR3 read. > + */ > + native_write_cr3(cr3); > +} > #else > static __always_inline void switch_to_kernel_cr3(void) {} > static __always_inline unsigned long ist_switch_to_kernel_cr3(void) { return 0; } > +static __always_inline void ist_restore_cr3(unsigned long cr3) {} > #endif > > /* >