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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C83AC433EF for ; Tue, 26 Oct 2021 14:39:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E15D360E8F for ; Tue, 26 Oct 2021 14:39:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235948AbhJZOlb (ORCPT ); Tue, 26 Oct 2021 10:41:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236835AbhJZOl3 (ORCPT ); Tue, 26 Oct 2021 10:41:29 -0400 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81940C061745 for ; Tue, 26 Oct 2021 07:39:05 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id n11-20020a17090a2bcb00b001a1e7a0a6a6so2484799pje.0 for ; Tue, 26 Oct 2021 07:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=GngOxReVA58jxFm4o8DBzLFQDbGENrJS7+p49FzXUf4=; b=FkG0GHuwH7x7uAlpS6f6+a5Sl6IOfrKLNZe7ErvB0qN5RoBqkvRH8j7oB7CFUqEdM7 5GygbtPxUhk9TGdS5H1aFcpygGr3rmqo83Yj7PjOgykCB8Lc3ZUuIFDDEdJzd0RK09kj dgWnqdw37GFNaHeH6W5xi85neZnt5bf07B9NpnTeJm/sl0w8OLIk7MgYe7l9rLRfwe1t 5FhilMTmwPMdIpNd8gPMjeQBA1dE+7zHtwjPa26gFmN3rOzUBU0a5SoD+Sj5/HRe++cq CGxf3YSSwmtfRp4lzom0LTZbOYFPnVZxc3yqZBkQ0laGH2hH3tmEx8sii4AFm8QQRfsk GVuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=GngOxReVA58jxFm4o8DBzLFQDbGENrJS7+p49FzXUf4=; b=VmxzWlkgjF+10K9E2g7qPgBui6urbnS2I97Eezmx5RvCHOUxuRUFoWF0xw4VyQB74s SBKKsXK5niTY+F/g/ir8bIq1Qg8Ir7cAv385hMwSvlsPHOtw1xoYmPpsh9pQcn9j2rPa +tYTE0d0JK/cWnHoL9gA+P+gF45ncvU9H6RzKbXVPplcfxufeJCUUeS8IFubECMrcSYY 8peZHXX7aaDvzYkGx0FRJy1nEH8V0EF4CbqIM8x1agiJe5QT6VvfbwSJlwqbtY7frS4i 3CPpRM3GjPk90Kh9eHtbPoUoMeizYa8CkkdvQ2emXP6vXJrImOpC+faqnESqvN7DMwBz i2ng== X-Gm-Message-State: AOAM530nTdX2J7BvZN3L2RAcmKlXW90gzRIfEvzZvBRsozwvh5vc8SGq sQrwEnL+2E6g95oI6hTp6Krq3G7AjMQ= X-Google-Smtp-Source: ABdhPJxVDK6szvh26nNTmbdCs5LWf3PHXWXsjmnJ6iMkt+2Ef44pqc0GAVz1+9tkKhQXkPTfcrn5nA== X-Received: by 2002:a17:902:b583:b0:13d:e495:187a with SMTP id a3-20020a170902b58300b0013de495187amr22687241pls.9.1635259144845; Tue, 26 Oct 2021 07:39:04 -0700 (PDT) Received: from localhost ([47.88.5.130]) by smtp.gmail.com with ESMTPSA id t13sm19495496pgn.94.2021.10.26.07.39.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Oct 2021 07:39:04 -0700 (PDT) From: Lai Jiangshan To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, Lai Jiangshan , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" Subject: [PATCH V4 48/50] x86/entry: Remove the unused ASM macros Date: Tue, 26 Oct 2021 22:38:46 +0800 Message-Id: <20211026143851.19481-4-jiangshanlai@gmail.com> X-Mailer: git-send-email 2.19.1.6.gb485710b In-Reply-To: <20211026141420.17138-1-jiangshanlai@gmail.com> References: <20211026141420.17138-1-jiangshanlai@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Lai Jiangshan They are implemented and used in C code. The ASM version is not needed any more. FENCE_SWAPGS_USER_ENTRY is not removed because it is still being used in the nmi userspace path. It could be possible to be removed in future entry code enhancement. Signed-off-by: Lai Jiangshan --- arch/x86/entry/calling.h | 99 ---------------------------------------- 1 file changed, 99 deletions(-) diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h index 9065c31d2875..d42012fc694d 100644 --- a/arch/x86/entry/calling.h +++ b/arch/x86/entry/calling.h @@ -210,53 +210,6 @@ For 32-bit we have the following conventions - kernel is built with popq %rax .endm -.macro SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg:req save_reg:req - ALTERNATIVE "jmp .Ldone_\@", "", X86_FEATURE_PTI - movq %cr3, \scratch_reg - movq \scratch_reg, \save_reg - /* - * Test the user pagetable bit. If set, then the user page tables - * are active. If clear CR3 already has the kernel page table - * active. - */ - bt $PTI_USER_PGTABLE_BIT, \scratch_reg - jnc .Ldone_\@ - - ADJUST_KERNEL_CR3 \scratch_reg - movq \scratch_reg, %cr3 - -.Ldone_\@: -.endm - -.macro RESTORE_CR3 scratch_reg:req save_reg:req - ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI - - /* No need to restore when the saved CR3 is kernel CR3. */ - bt $PTI_USER_PGTABLE_BIT, \save_reg - jnc .Lend_\@ - - ALTERNATIVE "jmp .Lwrcr3_\@", "", X86_FEATURE_PCID - - /* - * Check if there's a pending flush for the user ASID we're - * about to set. - */ - movq \save_reg, \scratch_reg - andq $(0x7FF), \scratch_reg - bt \scratch_reg, THIS_CPU_user_pcid_flush_mask - jnc .Lnoflush_\@ - - btr \scratch_reg, THIS_CPU_user_pcid_flush_mask - jmp .Lwrcr3_\@ - -.Lnoflush_\@: - SET_NOFLUSH_BIT \save_reg - -.Lwrcr3_\@: - movq \save_reg, %cr3 -.Lend_\@: -.endm - #else /* CONFIG_PAGE_TABLE_ISOLATION=n: */ .macro SWITCH_TO_KERNEL_CR3 scratch_reg:req @@ -265,10 +218,6 @@ For 32-bit we have the following conventions - kernel is built with .endm .macro SWITCH_TO_USER_CR3_STACK scratch_reg:req .endm -.macro SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg:req save_reg:req -.endm -.macro RESTORE_CR3 scratch_reg:req save_reg:req -.endm #endif @@ -277,17 +226,10 @@ For 32-bit we have the following conventions - kernel is built with * * FENCE_SWAPGS_USER_ENTRY is used in the user entry swapgs code path, to * prevent a speculative swapgs when coming from kernel space. - * - * FENCE_SWAPGS_KERNEL_ENTRY is used in the kernel entry non-swapgs code path, - * to prevent the swapgs from getting speculatively skipped when coming from - * user space. */ .macro FENCE_SWAPGS_USER_ENTRY ALTERNATIVE "", "lfence", X86_FEATURE_FENCE_SWAPGS_USER .endm -.macro FENCE_SWAPGS_KERNEL_ENTRY - ALTERNATIVE "", "lfence", X86_FEATURE_FENCE_SWAPGS_KERNEL -.endm .macro STACKLEAK_ERASE_NOCLOBBER #ifdef CONFIG_GCC_PLUGIN_STACKLEAK @@ -297,12 +239,6 @@ For 32-bit we have the following conventions - kernel is built with #endif .endm -.macro SAVE_AND_SET_GSBASE scratch_reg:req save_reg:req - rdgsbase \save_reg - GET_PERCPU_BASE \scratch_reg - wrgsbase \scratch_reg -.endm - #else /* CONFIG_X86_64 */ # undef UNWIND_HINT_IRET_REGS # define UNWIND_HINT_IRET_REGS @@ -313,38 +249,3 @@ For 32-bit we have the following conventions - kernel is built with call stackleak_erase #endif .endm - -#ifdef CONFIG_SMP - -/* - * CPU/node NR is loaded from the limit (size) field of a special segment - * descriptor entry in GDT. - */ -.macro LOAD_CPU_AND_NODE_SEG_LIMIT reg:req - movq $__CPUNODE_SEG, \reg - lsl \reg, \reg -.endm - -/* - * Fetch the per-CPU GSBASE value for this processor and put it in @reg. - * We normally use %gs for accessing per-CPU data, but we are setting up - * %gs here and obviously can not use %gs itself to access per-CPU data. - * - * Do not use RDPID, because KVM loads guest's TSC_AUX on vm-entry and - * may not restore the host's value until the CPU returns to userspace. - * Thus the kernel would consume a guest's TSC_AUX if an NMI arrives - * while running KVM's run loop. - */ -.macro GET_PERCPU_BASE reg:req - LOAD_CPU_AND_NODE_SEG_LIMIT \reg - andq $VDSO_CPUNODE_MASK, \reg - movq __per_cpu_offset(, \reg, 8), \reg -.endm - -#else - -.macro GET_PERCPU_BASE reg:req - movq pcpu_unit_offsets(%rip), \reg -.endm - -#endif /* CONFIG_SMP */ -- 2.19.1.6.gb485710b