Message ID | 20231003062458.23552-17-xin3.li@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp1899152vqb; Mon, 2 Oct 2023 23:56:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGtTjtvxtAOEzNzd6jdL16BWwxXK91kBJlGD7evs3h8vEcdenSq6SnMfpkcac4uDxciJQb3 X-Received: by 2002:a05:6358:280e:b0:13a:bd3:3f85 with SMTP id k14-20020a056358280e00b0013a0bd33f85mr14531765rwb.23.1696316206242; Mon, 02 Oct 2023 23:56:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696316206; cv=none; d=google.com; s=arc-20160816; b=dHpU7eP+t0pkzdUd1XawmjopeTjewDC80eq0iahtTiq00u9362V3OY9KLT60wGeVek bFuOm1nwlaFqGa6wPmw/PgpvqkJMAtDbJf3N7mIff4S+AyPSL7zzQTDL2pg6qA7HFbqT gumqjipdv8eXj9roou18z5yc+2gefhDjsv7wJ9NtGQ468PqN2smeWYxFzZPEJ/jEpWpw ylnjKYxclmUWHQiuwbHKiFIFFi6bi0U89KDYRLLjG3oDKDnVgneBeRMy8oLM+06RwF/v VuFGrid2mBCJ2xGMl4etiQi609ptsY31s3XEF41tX++vAtTzEczuoiVqI80K6F3yKAIT 2o/w== 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=ZfA7yoiCbqWgYh9wCguFnGhPlA0hs9ppoWHmxKgPSa8=; fh=Tb1p8S3iOxe/kX/WSNC3xEJzSVgGJ5DaxSrKb+pzH+4=; b=b1UT/1+G457wRynbA4NerUAwwpDFYAxzo35olUDcqEu8hBOeLQIJxvUJjcPiCTQ0wG yUVa8P2P5I+cYLUcd4PiSdFwa1859FnR+AuuGbpzV1klWhX7cy9USqZq7suguc4ylJkw hxnmxfqWGnZf06RMGuT3mR0ObTbnEICQ6gk9sgv11rP5rfeCd9f6ckwgsvZ2VnMqgfXt vxapy/aBYC3N3FxlfeZJiGdNFIxnPxrjI8sbwDz9Z2aPACA3B3dpdEtRqKhCQ0tebi6h fxYUhSZ3vGTeUdwgH8UFT7AOs7zcdK7s8wXyHBovYOxKtApr2SFwquDBdc3io1fvay+8 O+6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kGii2U8r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 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 howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id b18-20020a056a000a9200b0069338b22bfdsi868348pfl.205.2023.10.02.23.56.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 23:56:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kGii2U8r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 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 (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id ADF7B80A730C; Mon, 2 Oct 2023 23:55:39 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239352AbjJCGzY (ORCPT <rfc822;pusanteemu@gmail.com> + 18 others); Tue, 3 Oct 2023 02:55:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239183AbjJCGyx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 3 Oct 2023 02:54:53 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA6E6107; Mon, 2 Oct 2023 23:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1696316086; x=1727852086; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=V+OPmxsacyHhQwU2DRsayMn8eLFfcoR2lqYdblOZ50U=; b=kGii2U8rVWjB4mjtPAI+wr5f9N90M6Evml4WUwY4m/tVrW1fDZ8duQmL FRwATYYzX7YSCTGk6uFhsldgvuJE/9P+9Ib5xjxndykaQT6BMQ1Tjd1Xp ppnqq657h2DERj4rtBqIxWFD4F4sM0N/OC7e9lnrgMSMbKMNuaK227gS5 C8lIaJg2D6pbwzvwkx520GPnsY6CWtgZOMAo4eqXYB3TieRTJ6LKTBaKV f49Jz/1DpUdPpX9eqh34G1nqwjlvstiXrqz8ZLhFPaVRiw3vVTm6TWZY/ IuQawgWR1GTSeiaJBwrvDUdAhTaE1QEz0+aWCjCUahRjyecSGR/kphMct g==; X-IronPort-AV: E=McAfee;i="6600,9927,10851"; a="367858087" X-IronPort-AV: E=Sophos;i="6.03,196,1694761200"; d="scan'208";a="367858087" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Oct 2023 23:54:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10851"; a="1081900943" X-IronPort-AV: E=Sophos;i="6.03,196,1694761200"; d="scan'208";a="1081900943" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga005.fm.intel.com with ESMTP; 02 Oct 2023 23:54:42 -0700 From: Xin Li <xin3.li@intel.com> To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com, nik.borisov@suse.com Subject: [PATCH v12 16/37] x86/ptrace: Add FRED additional information to the pt_regs structure Date: Mon, 2 Oct 2023 23:24:37 -0700 Message-Id: <20231003062458.23552-17-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231003062458.23552-1-xin3.li@intel.com> References: <20231003062458.23552-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE 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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 02 Oct 2023 23:55:39 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778716462286369305 X-GMAIL-MSGID: 1778716462286369305 |
Series |
x86: enable FRED for x86-64
|
|
Commit Message
Li, Xin3
Oct. 3, 2023, 6:24 a.m. UTC
FRED defines additional information in the upper 48 bits of cs/ss fields. Therefore add the information definitions into the pt_regs structure. Specially introduce a new structure fred_ss to denote the FRED flags above SS selector, which avoids FRED_SSX_ macros and makes the code simpler and easier to read. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Tested-by: Shan Kang <shan.kang@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Xin Li <xin3.li@intel.com> --- Changes since v11: * Add a new structure fred_cs to denote the FRED flags above CS selector as what is done for SS (H. Peter Anvin). Changes since v9: * Introduce a new structure fred_ss to denote the FRED flags above SS selector, which avoids FRED_SSX_ macros and makes the code simpler and easier to read (Thomas Gleixner). * Use type u64 to define FRED bit fields instead of type unsigned int (Thomas Gleixner). Changes since v8: * Reflect stack frame definition changes from FRED spec 3.0 to 5.0. * Use __packed instead of __attribute__((__packed__)) (Borislav Petkov). * Put all comments above the members, like the rest of the file does (Borislav Petkov). Changes since v3: * Rename csl/ssl of the pt_regs structure to csx/ssx (x for extended) (Andrew Cooper). --- arch/x86/include/asm/ptrace.h | 70 ++++++++++++++++++++++++++++++++--- 1 file changed, 65 insertions(+), 5 deletions(-)
Comments
On Mon, Oct 02, 2023 at 11:24:37PM -0700, Xin Li wrote: > FRED defines additional information in the upper 48 bits of cs/ss > fields. Therefore add the information definitions into the pt_regs > structure. > > Specially introduce a new structure fred_ss to denote the FRED flags > above SS selector, which avoids FRED_SSX_ macros and makes the code > simpler and easier to read. > > Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> You and hpa need to go through all the patches and figure out who's the author that's going to land in git. Because this and others have hpa's SOB first, suggesting he's the author. However, the mail doesn't start with From: H. Peter Anvin (Intel) <hpa@zytor.com> and then git will make *you* the author. > Tested-by: Shan Kang <shan.kang@intel.com> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: Xin Li <xin3.li@intel.com> ... > union { > - u64 ssx; // The full 64-bit data slot containing SS > - u16 ss; // SS selector > + /* SS selector */ > + u16 ss; > + /* The extended 64-bit data slot containing SS */ > + u64 ssx; > + /* The FRED SS extension */ > + struct fred_ss fred_ss; Aha, sanity about the right comments has come to your mind in this next patch. :-P Just do them right in the previous one. > /* > - * Top of stack on IDT systems. > + * Top of stack on IDT systems, while FRED systems have extra fields > + * defined above for storing exception related information, e.g. CR2 or > + * DR6. Btw, I really appreciate the good commenting - thanks for that!
On November 28, 2023 12:51:22 AM PST, Borislav Petkov <bp@alien8.de> wrote: >On Mon, Oct 02, 2023 at 11:24:37PM -0700, Xin Li wrote: >> FRED defines additional information in the upper 48 bits of cs/ss >> fields. Therefore add the information definitions into the pt_regs >> structure. >> >> Specially introduce a new structure fred_ss to denote the FRED flags >> above SS selector, which avoids FRED_SSX_ macros and makes the code >> simpler and easier to read. >> >> Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> > >You and hpa need to go through all the patches and figure out who's the >author that's going to land in git. > >Because this and others have hpa's SOB first, suggesting he's the >author. However, the mail doesn't start with > >From: H. Peter Anvin (Intel) <hpa@zytor.com> > >and then git will make *you* the author. > >> Tested-by: Shan Kang <shan.kang@intel.com> >> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> >> Signed-off-by: Xin Li <xin3.li@intel.com> > >... > >> union { >> - u64 ssx; // The full 64-bit data slot containing SS >> - u16 ss; // SS selector >> + /* SS selector */ >> + u16 ss; >> + /* The extended 64-bit data slot containing SS */ >> + u64 ssx; >> + /* The FRED SS extension */ >> + struct fred_ss fred_ss; > >Aha, sanity about the right comments has come to your mind in this next >patch. :-P > >Just do them right in the previous one. > >> /* >> - * Top of stack on IDT systems. >> + * Top of stack on IDT systems, while FRED systems have extra fields >> + * defined above for storing exception related information, e.g. CR2 or >> + * DR6. > >Btw, I really appreciate the good commenting - thanks for that! > For Xin, mainly: Standard practice is: 1. For a patch with relatively small modifications, or where the changes are mainly in comments or the patch message: Keep the authorship, but put a description of what you have changed in brackets with your username at the bottom of the description, immediately before Signed-off-by: [ xin: changed foo, bar, baz ] 2. For a patch with major rewrites: Take authorship on the From: line, but have an Originally-by: tag (rather than a Signed-off-by: by the original author): Originally-by: Someone Else <someone@elsewhere.dom> 3. For a patch which is fully or nearly fully your own work (a total rewrite, or based on a concept idea rather than actual code), credit the original in the patch comment: Based on an idea by Someone Else <someone@elsewhere.dom> (optional link to lore.kernel.org).
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h index f08ea073edd6..5a83fbd9bc0b 100644 --- a/arch/x86/include/asm/ptrace.h +++ b/arch/x86/include/asm/ptrace.h @@ -56,6 +56,50 @@ struct pt_regs { #else /* __i386__ */ +struct fred_cs { + /* CS selector */ + u64 cs : 16, + /* Stack level at event time */ + sl : 2, + /* IBT in WAIT_FOR_ENDBRANCH state */ + wfe : 1, + : 45; +}; + +struct fred_ss { + /* SS selector */ + u64 ss : 16, + /* STI state */ + sti : 1, + /* Set if syscall, sysenter or INT n */ + swevent : 1, + /* Event is NMI type */ + nmi : 1, + : 13, + /* Event vector */ + vector : 8, + : 8, + /* Event type */ + type : 4, + : 4, + /* Event was incident to enclave execution */ + enclave : 1, + /* CPU was in long mode */ + lm : 1, + /* + * Nested exception during FRED delivery, not set + * for #DF. + */ + nested : 1, + : 1, + /* + * The length of the instruction causing the event. + * Only set for INTO, INT1, INT3, INT n, SYSCALL + * and SYSENTER. 0 otherwise. + */ + insnlen : 4; +}; + struct pt_regs { /* * C ABI says these regs are callee-preserved. They aren't saved on @@ -85,6 +129,12 @@ struct pt_regs { * - the syscall number (syscall, sysenter, int80) * - error_code stored by the CPU on traps and exceptions * - the interrupt number for device interrupts + * + * A FRED stack frame starts here: + * 1) It _always_ includes an error code; + * + * 2) The return frame for ERET[US] starts here, but + * the content of orig_ax is ignored. */ unsigned long orig_ax; @@ -92,20 +142,30 @@ struct pt_regs { unsigned long ip; union { - u64 csx; // The full 64-bit data slot containing CS - u16 cs; // CS selector + /* CS selector */ + u16 cs; + /* The extended 64-bit data slot containing CS */ + u64 csx; + /* The FRED CS extension */ + struct fred_cs fred_cs; }; unsigned long flags; unsigned long sp; union { - u64 ssx; // The full 64-bit data slot containing SS - u16 ss; // SS selector + /* SS selector */ + u16 ss; + /* The extended 64-bit data slot containing SS */ + u64 ssx; + /* The FRED SS extension */ + struct fred_ss fred_ss; }; /* - * Top of stack on IDT systems. + * Top of stack on IDT systems, while FRED systems have extra fields + * defined above for storing exception related information, e.g. CR2 or + * DR6. */ };