Message ID | 20230307023946.14516-6-xin3.li@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp2213620wrd; Mon, 6 Mar 2023 19:18:52 -0800 (PST) X-Google-Smtp-Source: AK7set8bCLNS8botawNyAiDWLLom7eQpgb7J8bAWiavDYM6eptOoG45ek6/DvKtMzpa+Jmo590Ev X-Received: by 2002:a17:906:948:b0:87f:5d0a:c610 with SMTP id j8-20020a170906094800b0087f5d0ac610mr13020291ejd.32.1678159132421; Mon, 06 Mar 2023 19:18:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678159132; cv=none; d=google.com; s=arc-20160816; b=MAaSu+VsVQS5r48OjDlaqSQuRcowmkun134RAgBjyp2RZAiImypKYoxUfOrRQCX/LO eG/6veWg2lnE/qwt7QrMVHGWv1ASk+3nbMrlMknXMR4fG7wtAtRD+0npjolHmxwMQ069 Z13XJc9SHPKaFJWyYp2yDJGoFuoZg8rBIIo5a3hSs0+WP7Qmeq5IOzoznrXxVvPGhyCH hnVvp3Zq7KOeoZOsCCnD8Ila03Jzb14PuhUHx18EpvFIKRnhUCvBDsuekbhFrqFv8BOi 09T46mbrx00IHfCuQ0Tf6iEf3tvLOcu2iTI3TnA+BXqddU8BEjWw/hCKXd3hFN5WfUhX RABQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ur43HcRHxkNKt7OW4fFLQmYxPRkbgPmxJPZDLkTVcCQ=; b=OtozZwa2HlHpghd4OUKyRvWczy5FYW8sD0mKrwm1iNqbeBLpFLmiriCJ4xPwy5cJRN SfCw2Tqq+//RWzqT+VE/M7AaedMJN7ht4Q2LGfWVCjXS9m2mXOOeCXhVlOxLkG+GAPcK k8YJ1V6OOEgKXhYXppyi9Nvt+4msi82KGP7Daz1jDlz9/HnwVreX+c8VZTmHnxQIOOpj GRMHx6nGVnpiTVw5WEeZbcggHk5rKgBK4IrAPp95rTUrOC7/CV9gXXSY2oLjWt2v9NDy OCVpyNwvG2gLc6vYTv0Uy5D3bt0TL+TgnIefWgetAD2wxC/ao1YR/jbqemXJNz8bhvLy stPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="MYk0z84/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bq7-20020a170906d0c700b008e0bd541c59si11068427ejb.188.2023.03.06.19.18.27; Mon, 06 Mar 2023 19:18:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="MYk0z84/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230299AbjCGDFl (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Mon, 6 Mar 2023 22:05:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230222AbjCGDFZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Mar 2023 22:05:25 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF39B74335; Mon, 6 Mar 2023 19:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678158319; x=1709694319; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=n5Ln656oJnJmTILrzTkjrWNEu25opZektOWvxvWKy2E=; b=MYk0z84/HgtYlx4WOUKXH+jbwrikWGWcC3MqpXTy7JSPJBqRs/FUgjNq hyP1c6C1lCUrXMVmmDb7LmEY3SbvSoWTlLSoJcR9xiwMaOnapfY3Z343t t91yld+NqNAm8zBszN0BR/94WQpJDHbsqAcEnIlYSMnyQHzX/sjxsKnHW DX4yOA6I7icVLa7rK731M9Lv5jf39cbMrBkjoAGCF6UZDXxjUw6FlSnq7 puDSdM17OAUHCPSUTIl3d00l3qJHjnAJie4KscyjyusKF0rHjCUCNzEBU 4nsdkOr73fjJtWsvqUYOg4I1yTr+tN4XXAOlmWD+Z3lD/L0Q2qcgI+jnT A==; X-IronPort-AV: E=McAfee;i="6500,9779,10641"; a="338072350" X-IronPort-AV: E=Sophos;i="5.98,238,1673942400"; d="scan'208";a="338072350" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Mar 2023 19:05:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10641"; a="676409724" X-IronPort-AV: E=Sophos;i="5.98,238,1673942400"; d="scan'208";a="676409724" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga002.jf.intel.com with ESMTP; 06 Mar 2023 19:05:11 -0800 From: Xin Li <xin3.li@intel.com> To: linux-kernel@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, andrew.cooper3@citrix.com, seanjc@google.com, pbonzini@redhat.com, ravi.v.shankar@intel.com Subject: [PATCH v5 05/34] x86/traps: export external_interrupt() for VMX IRQ reinjection Date: Mon, 6 Mar 2023 18:39:17 -0800 Message-Id: <20230307023946.14516-6-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230307023946.14516-1-xin3.li@intel.com> References: <20230307023946.14516-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759677390608645752?= X-GMAIL-MSGID: =?utf-8?q?1759677390608645752?= |
Series |
x86: enable FRED for x86-64
|
|
Commit Message
Li, Xin3
March 7, 2023, 2:39 a.m. UTC
To eliminate dispatching IRQ through the IDT, export external_interrupt() for VMX IRQ reinjection. Tested-by: Shan Kang <shan.kang@intel.com> Signed-off-by: Xin Li <xin3.li@intel.com> --- arch/x86/include/asm/traps.h | 2 ++ arch/x86/kernel/traps.c | 14 ++++++++++++++ 2 files changed, 16 insertions(+)
Comments
On Mon, Mar 06, 2023, Xin Li wrote: > To eliminate dispatching IRQ through the IDT, export external_interrupt() > for VMX IRQ reinjection. > > Tested-by: Shan Kang <shan.kang@intel.com> > Signed-off-by: Xin Li <xin3.li@intel.com> > --- > arch/x86/include/asm/traps.h | 2 ++ > arch/x86/kernel/traps.c | 14 ++++++++++++++ > 2 files changed, 16 insertions(+) > > diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h > index 46f5e4e2a346..da4c21ed68b4 100644 > --- a/arch/x86/include/asm/traps.h > +++ b/arch/x86/include/asm/traps.h > @@ -56,4 +56,6 @@ void __noreturn handle_stack_overflow(struct pt_regs *regs, > void f (struct pt_regs *regs) > typedef DECLARE_SYSTEM_INTERRUPT_HANDLER((*system_interrupt_handler)); > > +int external_interrupt(struct pt_regs *regs, unsigned int vector); > + > #endif /* _ASM_X86_TRAPS_H */ > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > index 31ad645be2fb..cebba1f49e19 100644 > --- a/arch/x86/kernel/traps.c > +++ b/arch/x86/kernel/traps.c > @@ -1540,6 +1540,20 @@ int external_interrupt(struct pt_regs *regs, unsigned int vector) > return 0; > } > > +#if IS_ENABLED(CONFIG_KVM_INTEL) > +/* > + * KVM VMX reinjects IRQ on its current stack, it's a sync call > + * thus the values in the pt_regs structure are not used in > + * executing IRQ handlers, except cs.RPL and flags.IF, which > + * are both always 0 in the VMX IRQ reinjection context. > + * > + * However, the pt_regs structure is sometimes used in stack > + * dump, e.g., show_regs(). So let the caller, i.e., KVM VMX > + * decide how to initialize the input pt_regs structure. > + */ > +EXPORT_SYMBOL_GPL(external_interrupt); > +#endif If the x86 maintainers don't object, I would prefer this to be squashed with the actual KVM usage, that way discussions on exactly what the exported API should be can be contained in a single thread.
> > +#if IS_ENABLED(CONFIG_KVM_INTEL) > > +/* > > + * KVM VMX reinjects IRQ on its current stack, it's a sync call > > + * thus the values in the pt_regs structure are not used in > > + * executing IRQ handlers, except cs.RPL and flags.IF, which > > + * are both always 0 in the VMX IRQ reinjection context. > > + * > > + * However, the pt_regs structure is sometimes used in stack > > + * dump, e.g., show_regs(). So let the caller, i.e., KVM VMX > > + * decide how to initialize the input pt_regs structure. > > + */ > > +EXPORT_SYMBOL_GPL(external_interrupt); > > +#endif > > If the x86 maintainers don't object, I would prefer this to be squashed with the > actual KVM usage, that way discussions on exactly what the exported API should be > can be contained in a single thread. The KVM usage is the only one now, thus it does make sense to squash into one. I'm working on v6 and will merge this patch into the corresponding KVM patch. BTW, I will stop using "reinject" as asked.
diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h index 46f5e4e2a346..da4c21ed68b4 100644 --- a/arch/x86/include/asm/traps.h +++ b/arch/x86/include/asm/traps.h @@ -56,4 +56,6 @@ void __noreturn handle_stack_overflow(struct pt_regs *regs, void f (struct pt_regs *regs) typedef DECLARE_SYSTEM_INTERRUPT_HANDLER((*system_interrupt_handler)); +int external_interrupt(struct pt_regs *regs, unsigned int vector); + #endif /* _ASM_X86_TRAPS_H */ diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 31ad645be2fb..cebba1f49e19 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -1540,6 +1540,20 @@ int external_interrupt(struct pt_regs *regs, unsigned int vector) return 0; } +#if IS_ENABLED(CONFIG_KVM_INTEL) +/* + * KVM VMX reinjects IRQ on its current stack, it's a sync call + * thus the values in the pt_regs structure are not used in + * executing IRQ handlers, except cs.RPL and flags.IF, which + * are both always 0 in the VMX IRQ reinjection context. + * + * However, the pt_regs structure is sometimes used in stack + * dump, e.g., show_regs(). So let the caller, i.e., KVM VMX + * decide how to initialize the input pt_regs structure. + */ +EXPORT_SYMBOL_GPL(external_interrupt); +#endif + void __init trap_init(void) { /* Init cpu_entry_area before IST entries are set up */