From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234221; cv=none; d=zohomail.com; s=zohoarc; b=cdMjDN6/37ELpNE5fR1cYgXAKGx7pmGwRxBWt3XSnIwIFNCa9gQfSevHlQt6BEMa9pMAOz4qU81SZN2nn1qPWDs5GVMWZMqtr+YU/ivg0y8OAIJbRPSlIEnomF16n7v2vYp4sRhmzT+ZAlP1FVGbYLIWSkScyfReSQbxZpsqH4c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234221; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=qm1+0hl5wg0cTPkZkQcfwjLCPbdvhVekwrZIT03s7DQ=; b=XqDrAUy/x9zCMRDtrYKguPZ0Kx/WFgJ31V192RAagsAOOuaYOH8+fiUW+N0WB5mLYzKh71kH2YOZUrfaZl57y1EpUM9swX9ZcXQZhqpEcTCB6HEdwRppvirX3bUGOB2UjYq/XwjteDucxF+/31ldLUTszws+MNflMMzBbNRfrFg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234221180152.98981605259178; Fri, 27 Feb 2026 15:17:01 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243138.1543132 (Exim 4.92) (envelope-from ) id 1vw74f-0000jx-4G; Fri, 27 Feb 2026 23:16:45 +0000 Received: by outflank-mailman (output) from mailman id 1243138.1543132; Fri, 27 Feb 2026 23:16:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74e-0000jq-Vy; Fri, 27 Feb 2026 23:16:44 +0000 Received: by outflank-mailman (input) for mailman id 1243138; Fri, 27 Feb 2026 23:16:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74d-0008WD-T1 for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:43 +0000 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [2a00:1450:4864:20::42f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 60dd154e-1432-11f1-b164-2bf370ae4941; Sat, 28 Feb 2026 00:16:43 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-436309f1ad7so2114584f8f.3 for ; Fri, 27 Feb 2026 15:16:43 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:40 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 60dd154e-1432-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234202; x=1772839002; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qm1+0hl5wg0cTPkZkQcfwjLCPbdvhVekwrZIT03s7DQ=; b=NhvaORhEENEHrYdMpzFOb00mPzdMS8s5p3eibErAyaHS4HN5cZMw0VCwtVsAfoVCUS FezmlqiwMN81ItFbwEasbRZTCpP7QdY5HXGERw0ZvGFlDrA39NOOpy8G0qLUmGn1WCdf vsr6rSX0DSuobDRlofwDyt9M2ufMohsvkWFH8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234202; x=1772839002; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qm1+0hl5wg0cTPkZkQcfwjLCPbdvhVekwrZIT03s7DQ=; b=jtbBe6sK4hUekdOHZSj7/gFRhXMsOehouPHBhHPFf7DYOVCnFV/urAr5LClLPMJdmu c3I6yYQ8N0NonZbel7gmPgTx0BsZIgVfi500ltLJOwig1JcUZBOKX1FHnw4Aj1v0kq7M rsgAUk6e3qR/U1xMiTejgkeIghFYVEmMQMHrT8GiURTpy8bFUI0noz8ShoQLj/3ex8zO 66Zs2FxqyVARxEhvMUzkKHb0N65OyfjUIbqnqRZfHNmRUnVL64FCcy9xpOrXFCNQThP1 0M+7YyLN0/bZMdJ4QVeY1ieaiM2kNJ69H7lzcwQ+YrAZKMAsQO39SrY87OO1FviCd/F2 y30g== X-Gm-Message-State: AOJu0YxWfm9Xw5aMV35qa9obqqE3HDHEVJt3OcxxxOuS2v4fIVM3GkQE 6t2XNUXH1ME0OLfmrOOOjUldlDtmsoObosKQp/43B7PdKlw4bF58gAsQMjuXRGUAbpbVBv9cjSj q+BMS X-Gm-Gg: ATEYQzwOOi0gYW1S98Cu8s0fLFST1in5LE8muKd2HEcSE0ilbhs60OlAjjc4JjQjObp GKx6JPoNKAgJqiX9Syk3x8ZSMK807qwS5tkHn0wie++zk9JNIx5pNedmw1Dgqgr4VvxCzH1eqle odeSkCUQM+wn94ktZUF9JJSeMfPpQ2zT7TYfwL2b9wpkIfWdwZADGNrKncfgjg9PMlnPlaHvvVg VE8iN2ydvjBKl1fgX1a6ck9BKlMzmBwOFaVFDcNEpYZSxkeSlilcX8kT70MjouHu6HKsDud+Grh Qp0Rx3CP3wAfYndQs8aB3t0vCIfUCd8tC2BWNzxQwy6gXhN/3CkxFH4C5ePhCXFKrqf6dR3DxyY PJw8VvXnw++M6RWMMZ+5m+J2Z0pTlv21J7V6okdA/m2CG7hHW2atBFq/QJxfAvO114wkmUHc3VA 4Wm56gSxcj574NYLqxR0BPqgT5DNW4siz1zy8+r7SJkcxjYbLkWk9xECn4X6tuf1uuGUcCvdI= X-Received: by 2002:a05:6000:2313:b0:439:84cb:288d with SMTP id ffacd0b85a97d-4399de2cb36mr7877033f8f.41.1772234201407; Fri, 27 Feb 2026 15:16:41 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 01/14] x86/pv: Don't assume that INT $imm8 instructions are two bytes long Date: Fri, 27 Feb 2026 23:16:23 +0000 Message-Id: <20260227231636.3955109-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234222339158500 For INT $N instructions (besides $0x80 for which there is a dedicated fast path), handling is mostly fault-based because of DPL0 gates in the IDT. Th= is means that when the guest kernel allows the instruction too, Xen must increment %rip to the end of the instruction before passing a trap to the guest kernel. When an INT $N instruction has a prefix, it's longer than two bytes, and Xen will deliver the "trap" with %rip pointing into the middle of the instructi= on. Introduce a new pv_emulate_sw_interrupt() which uses x86_insn_length() to determine the instruction length, rather than assuming two. This is a change in behaviour for PV guests, but the prior behaviour cannot reasonably be said to be intentional. This change does not affect the INT $0x80 fastpath. Prefixed INT $N instructions occur almost exclusively in test code or exploits, and INT $0x= 80 appears to be the only user-usable interrupt gate in contemporary PV guests. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * New --- xen/arch/x86/include/asm/pv/traps.h | 2 ++ xen/arch/x86/pv/emul-priv-op.c | 48 +++++++++++++++++++++++++++++ xen/arch/x86/traps.c | 3 +- 3 files changed, 51 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/include/asm/pv/traps.h b/xen/arch/x86/include/asm= /pv/traps.h index 8c201190923d..16e9a8d2aa3f 100644 --- a/xen/arch/x86/include/asm/pv/traps.h +++ b/xen/arch/x86/include/asm/pv/traps.h @@ -17,6 +17,7 @@ int pv_raise_nmi(struct vcpu *v); =20 int pv_emulate_privileged_op(struct cpu_user_regs *regs); +void pv_emulate_sw_interrupt(struct cpu_user_regs *regs); void pv_emulate_gate_op(struct cpu_user_regs *regs); bool pv_emulate_invalid_op(struct cpu_user_regs *regs); =20 @@ -31,6 +32,7 @@ static inline bool pv_trap_callback_registered(const stru= ct vcpu *v, static inline int pv_raise_nmi(struct vcpu *v) { return -EOPNOTSUPP; } =20 static inline int pv_emulate_privileged_op(struct cpu_user_regs *regs) { r= eturn 0; } +static inline void pv_emulate_sw_interrupt(struct cpu_user_regs *regs) {} static inline void pv_emulate_gate_op(struct cpu_user_regs *regs) {} static inline bool pv_emulate_invalid_op(struct cpu_user_regs *regs) { ret= urn true; } =20 diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index a3c1fd12621d..87d3bbcf901f 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -8,6 +8,7 @@ */ =20 #include +#include #include #include #include @@ -1401,6 +1402,53 @@ int pv_emulate_privileged_op(struct cpu_user_regs *r= egs) return 0; } =20 +/* + * Hardware already decoded the INT $N instruction and determinted that th= ere + * was a DPL issue, hence the #GP. Xen has already determined that the gu= est + * kernel has permitted this software interrupt. + * + * All that is needed is the instruction length, to turn the fault into a + * trap. All errors are turned back into the original #GP, as that's the + * action that really happened. + */ +void pv_emulate_sw_interrupt(struct cpu_user_regs *regs) +{ + struct vcpu *curr =3D current; + struct domain *currd =3D curr->domain; + struct priv_op_ctxt ctxt =3D { + .ctxt.regs =3D regs, + .ctxt.lma =3D !is_pv_32bit_domain(currd), + }; + struct x86_emulate_state *state; + uint8_t vector =3D regs->error_code >> 3; + unsigned int len, ar; + + if ( !pv_emul_read_descriptor(regs->cs, curr, &ctxt.cs.base, + &ctxt.cs.limit, &ar, 1) || + !(ar & _SEGMENT_S) || + !(ar & _SEGMENT_P) || + !(ar & _SEGMENT_CODE) ) + goto error; + + state =3D x86_decode_insn(&ctxt.ctxt, insn_fetch); + if ( IS_ERR_OR_NULL(state) ) + goto error; + + len =3D x86_insn_length(state, &ctxt.ctxt); + x86_emulate_free_state(state); + + /* Note: Checked slightly late to simplify 'state' handling. */ + if ( ctxt.ctxt.opcode !=3D 0xcd /* INT $imm8 */ ) + goto error; + + regs->rip +=3D len; + pv_inject_sw_interrupt(vector); + return; + + error: + pv_inject_hw_exception(X86_EXC_GP, regs->entry_vector); +} + /* * Local variables: * mode: C diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 5feac88d6c0b..907fb4c186c0 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1379,8 +1379,7 @@ void do_general_protection(struct cpu_user_regs *regs) =20 if ( permit_softint(TI_GET_DPL(ti), v, regs) ) { - regs->rip +=3D 2; - pv_inject_sw_interrupt(vector); + pv_emulate_sw_interrupt(regs); return; } } --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234240; cv=none; d=zohomail.com; s=zohoarc; b=YalbGfX3ZGfHXigWl1ZY2KGi9yA+aNdHFGcFtDfSC/Hp+FXup52cKkzkPWreK+Q7+WGBhqW9TxzmLnKuGZKIG8DZcvQnE2GQACgkezxXjP23oBGmlsGB64RY9pxlfomw/tZjXctj21X2HmsZRW9L8QuJDcvjRLpEAumG4gbclBA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234240; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=XgdpzNU2ggPbFTgmu4VQz6T9b6r+7R4jXsnlPDE3Rcg=; b=Co5fSXOzIC8NtWnk8473s5njbeSrw+4CHoMlXnTSLogh2B1/ujSVQSQVLY2NADau4W4ZdpEcifLoZLGp9PpjBXJ6Xqk76LdNFREayuf1JOCQShKVnTLGIz8S2RBsAU0D/HW67p7Z+6dizKY9y9V7f6IAPQ5jjed+0wV0YAyQiFY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234240385511.24800571184267; Fri, 27 Feb 2026 15:17:20 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243147.1543201 (Exim 4.92) (envelope-from ) id 1vw74p-0002RR-Gl; Fri, 27 Feb 2026 23:16:55 +0000 Received: by outflank-mailman (output) from mailman id 1243147.1543201; Fri, 27 Feb 2026 23:16:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74p-0002R4-7r; Fri, 27 Feb 2026 23:16:55 +0000 Received: by outflank-mailman (input) for mailman id 1243147; Fri, 27 Feb 2026 23:16:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74n-0001Do-0Y for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:53 +0000 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [2a00:1450:4864:20::436]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 61d57dc2-1432-11f1-9ccf-f158ae23cfc8; Sat, 28 Feb 2026 00:16:44 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-4375d4fb4d4so1676483f8f.0 for ; Fri, 27 Feb 2026 15:16:44 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:41 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 61d57dc2-1432-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234204; x=1772839004; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=XgdpzNU2ggPbFTgmu4VQz6T9b6r+7R4jXsnlPDE3Rcg=; b=NHLWGZQfYMaqUS/TGKOv5SxPxfjZXs9FFoH+q1SFnWgC+VSzNCtVY3yYo4DJkdeaEe 2snzK35OXTjfKKkGbtlWZmM9oD9MugXYCiYwCbBXTo/U5gCXtli5LHVnADr8UnvNP9n5 WfLp1NMIUDoNk/9ZcExzZo57GoZA3SaOsEIUQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234204; x=1772839004; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XgdpzNU2ggPbFTgmu4VQz6T9b6r+7R4jXsnlPDE3Rcg=; b=Ru1sBgrIwWgS0SBT+bzWP0s/rlq3QpigeUxOUNx5Ss6rk8vEABOC/9H7vHqGAEqoeW 6vCR/nK+BbEPCak8PmGWqvFhnSOYOn8Pcx3Z2I0qI5kMQ312Vu5xsrb6BKFKQUUCYUGL u6GGXWolKmvaLkTrFr76pqdSbyL+t10gMeSkfxFET53Om7ixD/OIgkkPpl955cG5ZXTd KzkNiwAVYUOB6fkeNz/HHETDCQGdXH14ZNQ6ie8vHwoLIedw2NZ+UHreMYaD2qEX6DPr lYZsxM6m9QOG1iDB+67GxRfp2JYLdQqIatp/SQhj5ugUSL6SFqec25iLaShyQMEIqmAI Fyzw== X-Gm-Message-State: AOJu0Yyvw0A8CToqUVAGGeQSlQ9Ief5UBEUKW7LWZLtZi44eOXEDbEX7 br8yQMmqN8AwgsBaWKMT4UXI1+dv0zvuSGcNYhaYrbLRGXn5i4GzQ+SuJ2LdAc3w8gRBoE76hkE KVnqB X-Gm-Gg: ATEYQzwFJhY2pvvPWauC8sr1+iqhPKbXOp9/LiLG7q6P2bzQdo8g2kjSwV8RWK7zaUG ziuQM5w9FyVTNpKKzkr+Fgffzed3jJ3+MG7/SEiD7cZdxhH5x2wj6tFSgRrnPIzM3rU/AD0rjz3 0wgyZzGbfcz+p9xc/h02/4uJ//eqVACbRgDDiBKQmMPOYwRga/OTjyNLd65JPoscsmfcuXqR6mm DnLp4cEMWuY8wH0i8RQuhlfxbrDe40ObarrMDtZl/TYbTcuIbfUe793/Ms4QURbx8UgEvu3O+ET xIyN4Ijd8SqdSOEXBYvrpaVeVloWtj6hROhVpu+YaKNasz2Z5924BpmTTnNiZM1mi3F6E8grVdX x2Fk2DHezKNjiv/VRklyBkpAGbHkIcXZYVi74cpEucftIMboO6V+c4LquWsMw1eiqizmzhMDlU0 vZhojuy1rfg2nBD5g60yIFHigapjSLPD022QLLHbi1q5WR4YenbKU6vifv8DkDTgAfshyZ4p0= X-Received: by 2002:a05:6000:420d:b0:439:8a4f:5250 with SMTP id ffacd0b85a97d-4399dde503fmr7936970f8f.17.1772234203211; Fri, 27 Feb 2026 15:16:43 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 02/14] docs/guest-guide: Describe the PV traps and entrypoints ABI Date: Fri, 27 Feb 2026 23:16:24 +0000 Message-Id: <20260227231636.3955109-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234242397158500 ... seeing as I've had to thoroughly reverse engineer it for FRED and make tweaks in places. Signed-off-by: Andrew Cooper Acked-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 Obviously there's a lot more in need of doing, but this is at least a start. v4: * New --- docs/glossary.rst | 3 + docs/guest-guide/x86/index.rst | 1 + docs/guest-guide/x86/pv-traps.rst | 123 ++++++++++++++++++++++++++++++ 3 files changed, 127 insertions(+) create mode 100644 docs/guest-guide/x86/pv-traps.rst diff --git a/docs/glossary.rst b/docs/glossary.rst index 6adeec77e14c..c8ab2386bc6e 100644 --- a/docs/glossary.rst +++ b/docs/glossary.rst @@ -43,6 +43,9 @@ Glossary Sapphire Rapids (Server, 2023) CPUs. AMD support only CET-SS, starti= ng with Zen3 (Both client and server, 2020) CPUs. =20 + event channel + A paravirtual facility for guests to send and recieve interrupts. + guest The term 'guest' has two different meanings, depending on context, and should not be confused with :term:`domain`. diff --git a/docs/guest-guide/x86/index.rst b/docs/guest-guide/x86/index.rst index 502968490d9d..5b38ae397a9f 100644 --- a/docs/guest-guide/x86/index.rst +++ b/docs/guest-guide/x86/index.rst @@ -7,3 +7,4 @@ x86 :maxdepth: 2 =20 hypercall-abi + pv-traps diff --git a/docs/guest-guide/x86/pv-traps.rst b/docs/guest-guide/x86/pv-tr= aps.rst new file mode 100644 index 000000000000..2ff18e2f9454 --- /dev/null +++ b/docs/guest-guide/x86/pv-traps.rst @@ -0,0 +1,123 @@ +.. SPDX-License-Identifier: CC-BY-4.0 + +PV Traps and Entrypoints +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +.. note:: + + The details here are specific to 64bit builds of Xen. Details for 32bit + builds of Xen, are different and not discussed further. + +PV guests are subject to Xen's linkage setup for events (interrupts, +exceptions and system calls). x86's IDT architecture and limitations are = the +majority influence on the PV ABI. + +All external interrupts are routed to PV guests via the :term:`Event Chann= el` +interface, and not discussed further here. + +What remain are exceptions, and the instructions which cause a control +transfers. In the x86 architecture, the instructions relevant for PV gues= ts +are: + + * ``INT3``, which generates ``#BP``. + + * ``INTO``, which generates ``#OF`` only if the overflow flag is set. It= is + only usable in compatibility mode, and will ``#UD`` in 64bit mode. + + * ``CALL (far)`` referencing a gate in the GDT. + + * ``INT $N``, which invokes an arbitrary IDT gate. These four instructio= ns + so far all check the gate DPL and will ``#GP`` otherwise. + + * ``INT1``, also known as ``ICEBP``, which generates ``#DB``. This + instruction does *not* check DPL, and can be used unconditionally by + userspace. + + * ``SYSCALL``, which enters CPL0 as configured by the ``{C,L,}STAR`` MSRs. + It is usable if enabled by ``MSR_EFER.SCE``, and will ``#UD`` otherwise. + On Intel parts, ``SYSCALL`` is unusable outside of 64bit mode. + + * ``SYSENTER``, which enters CPL0 as configured by the ``SEP`` MSRs. It = is + usable if enabled by ``MSR_SYSENTER_CS`` having a non-NUL selector, and + will ``#GP`` otherwise. On AMD parts, ``SYSENTER`` is unusable in Long + mode. + + +Xen's configuration +------------------- + +Xen maintains a complete IDT, with most gates configured with DPL0. This +causes most ``INT $N`` instructions to ``#GP``. This allows Xen to emulate +the instruction, referring to the guest kernels vDPL choice. + + * Vectors 3 ``#BP`` and 4 ``#OF`` are DPL3, in order to allow the ``INT3`` + and ``INTO`` instructions to function in userspace. + + * Vector 0x80 is DPL3 in order to implement the legacy system call fastpa= th + commonly found in UNIXes. + + * Vector 0x82 is DPL1 when PV32 is enabled, allowing the guest kernel to = make + hypercalls to Xen. All other cases (PV32 guest userspace, and both PV64 + modes) operate in CPL3 and this vector behaves like all others to ``INT + $N`` instructions. + +A range of the GDT is guest-owned, allowing for call gates. During audit,= Xen +forces all call gates to DPL0, causing their use to ``#GP`` allowing for +emulation. + +Xen enables ``SYSCALL`` in all cases as it is mandatory in 64bit mode, and +enables ``SYSENTER`` when available in 64bit mode. + +When Xen is using FRED delivery the hardware configuration is substantially +different, but the behaviour for guests remains as unchanged as possible. + + +PV Guest's configuration +------------------------ + +The PV ABI contains the "trap table", modelled very closely on the IDT. I= t is +manipulated by ``HYPERCALL_set_trap_table``, has 256 entries, each contain= ing +a code segment selector, an address, and flags. A guest is expected to +configure handlers for all exceptions; failure to do so is terminal simila= r to +a Triple Fault. + +Part of the GDT is guest owned with descriptors audited by Xen. This range +can be manipulated with ``HYPERVISOR_set_gdt`` and +``HYPERVISOR_update_descriptor``. + +Other entrypoints are configured via ``HYPERVISOR_callback_op``. Of note = here +are the callback types ``syscall``, ``syscall32`` (relevant for AMD parts)= and +``sysenter`` (relevant for Intel parts). + +.. warning:: + + Prior to Xen 4.15, there was no check that the ``syscall`` or ``syscall= 32`` + callbacks had been registered before attempting to deliver via them. + Guests are strongly advised to ensure the entrypoints are registered be= fore + running userspace. + + +Notes +----- + +``INT3`` vs ``INT $3`` and ``INTO`` vs ``INT $4`` are hard to distinguish +architecturally as both forms have a DPL check and use the same IDT vector= s. +Because Xen configures both as DPL3, the ``INT $`` forms do not fault for +emulation, and are treated as if they were exceptions. This means the gue= st +can't block these instruction by trying to configure them with vDPL0. + +The instructions which trap into Xen (``INT $0x80``, ``SYSCALL``, +``SYSENTER``) but can be disabled by guest configuration need turning back +into faults for the guest kernel to process. + + * When using IDT delivery, instruction lengths are not provided by hardwa= re + and Xen does not account for possible prefixes. ``%rip`` only gets rew= ound + by the length of the unprefixed instruction. This is observable, but n= ot + expected to be an issue in practice. + + * When Xen is using FRED delivery, the full instruction length is provide= d by + hardware, and ``%rip`` is rewound fully. + +While both PV32 and PV64 guests are permitted to write Call Gates into the +GDT, emulation is only wired up for PV32. At the time of writing, the x86 +maintainers feel no specific need to fix this omission. --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234225; cv=none; d=zohomail.com; s=zohoarc; b=iNurRkcuEhW003vKKMu+taduZKU5MuHPpdDq97cbqmhiKxWidMoTN2+Enye7sUUvbDDx3KaG3/74dfw60piJIuK8TxXKP6PQebNHg2gFSWNDhE+b8Lzzb1cyy7cHnxArMoHDx52ZuTmgVrMpf46QsxV9ch3ranJuvS/Ouk2RSi8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234225; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=TX7N+xBo3CKWjKGYcEu3yVytP4MNoG1haUKZc0lx4fI=; b=YCr/mt3tdt/lLNaCSEr8oPVkgJLTx+bJQfwDTFuvXjDyiZUfl80JKQF4Cn09Fs449S76sJr3knx5BTGlLph/rXC7G6skqWVyX6T9oY95yhrR+hSwzaNOpNePFPmQfDWj47g+ap5EKL7U0MVljpT2KFSySv9IXXDzgw9ne/I99mE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 17722342258910.5906021793852005; Fri, 27 Feb 2026 15:17:05 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243139.1543142 (Exim 4.92) (envelope-from ) id 1vw74h-0000z5-EX; Fri, 27 Feb 2026 23:16:47 +0000 Received: by outflank-mailman (output) from mailman id 1243139.1543142; Fri, 27 Feb 2026 23:16:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74h-0000yy-9V; Fri, 27 Feb 2026 23:16:47 +0000 Received: by outflank-mailman (input) for mailman id 1243139; Fri, 27 Feb 2026 23:16:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74g-0008WD-0E for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:46 +0000 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [2a00:1450:4864:20::430]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 62230be6-1432-11f1-b164-2bf370ae4941; Sat, 28 Feb 2026 00:16:45 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-4377174e1ebso1836355f8f.3 for ; Fri, 27 Feb 2026 15:16:45 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:43 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 62230be6-1432-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234205; x=1772839005; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TX7N+xBo3CKWjKGYcEu3yVytP4MNoG1haUKZc0lx4fI=; b=j04eYEweWDmZHEcA/r2rrbSeC2I3fwjS6PA6ycF2hylZhU1yY6/YT6xczlGJC5b2FB e+RNfvrQ+WX8JrpF7xS/Gvmriel20JQjAtkF+zWqR6tBz3pZGec/nmmK+cyeY3dwlu84 yKHqg/mllapkc0BsRO/7B3sWKxR7BmrH23qj8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234205; x=1772839005; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TX7N+xBo3CKWjKGYcEu3yVytP4MNoG1haUKZc0lx4fI=; b=mpLnU3o9SP2p57dwKSibpFkbN/N7sfG6uG1TylbLQNF5EMbsi9Gwpe51rYojOrjRrs t87EzUM8/2/fFaUtd7n2N29ZKt3Mc59J739TR2zT1kfjbmbZNHXA8bjYDlfuIQ5w9i72 TlSzFrkWGmhGuxvBWDmtMexqqvBCuOtkQYKw7iSRwIp1sYLgRr8QznJ+cQbFMPg5DuW2 Ts1QeyslYJOgZk4FxBRSCMNw9ps4ErMMn8dCZ6FVYBmqJP656MvYLUWMecF+5k7hSBfq dLMWPcjw7lpJ+v+cc+MENU1UzV9ZP0/RDjYJ2zEbakt3W3PolfoSJatCuVquz6KeAUJM rRYA== X-Gm-Message-State: AOJu0YwCMOgIkoqFepmQNOEtJO1Au+D+YdtJHA7vcpKkCkPxNtl44FQK Qgu/nzwhSKjfbiLJW412eBZaPTrWzcni+NB0pDoQhS/+K0i1k6lMSWcEyxLEYzMkUGeXz9wm7rM UCSUSD+2pUg== X-Gm-Gg: ATEYQzwt0uZ+xr3rLVe8irA//00e6Tq6juKNP1r/uFaxI0329402343fKBjKDjgKkvT Q+HhNLRtPoXPV8tw9+fes6vGPshQYkwenE5hEe3s0LkZXPnUIQr0KcUDKFW9prWSSEkMz7UcXJj ppDF1iD2zMLZGagF/PqwoiHeBwNKugbGGhOIyNnZax6paV9RgDBOhW8KH16M6MKtoVJ4mtmyOFN JORI9JScVG5lzqZyedMevH7JD4Kp6o62D9Jz3Ul0SbMZ8IgOe7RWBrr8E8nLdSAdWiTlfvpRKew 3zZInYtKtL7tJzkA+NndJzj+TM5jdx30g8YFP/EioJhzAqj3tRqZT/nwsxmV1uY/EBN8kqLE2QF whoDW9vlBEqcCkDfn01p11yw7S8//YjSSyTvGnBQSbKUJEL+9HE3YAOKiT4QLK/yEfodfuw6Kaj TKF6b0j5TQzkcs7PHP4qvnkEu3LOZxhXFeAYvJ1DMSLw4MX/ZKGHpDgk0tAqddMrPUMacpJAE= X-Received: by 2002:a05:6000:310a:b0:437:6f0c:2ed with SMTP id ffacd0b85a97d-4399de2b59dmr8038457f8f.34.1772234204503; Fri, 27 Feb 2026 15:16:44 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 03/14] x86/boot: Move gdt_l1e caching out of traps_init() Date: Fri, 27 Feb 2026 23:16:25 +0000 Message-Id: <20260227231636.3955109-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234226324158500 Commit 564d261687c0 ("x86/ctxt-switch: Document and improve GDT handling") = put the initialisation of {,compat_}gdt_l1e into traps_init() but this wasn't a great choice. Instead, put it in smp_prepare_cpus() which performs the BSP preparation of variables normally set up by cpu_smpboot_alloc() for APs. This removes an implicit dependency that prevents traps_init() moving earli= er than move_xen() in the boot sequence. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * New I'm on the fence about the ASSERT(), but I'm getting rather tired of unstat= ed dependencies. For a PV64 guest using SYSEXIT to enter the guest, it's the first interrupt/exception which references the GDT, which could be after the guest is running. --- xen/arch/x86/domain.c | 2 ++ xen/arch/x86/smpboot.c | 11 +++++++++++ xen/arch/x86/traps-setup.c | 7 ------- 3 files changed, 13 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 8eb1509782ef..e658c2d647b7 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -2029,6 +2029,8 @@ static always_inline bool need_full_gdt(const struct = domain *d) =20 static void update_xen_slot_in_full_gdt(const struct vcpu *v, unsigned int= cpu) { + ASSERT(per_cpu(gdt_l1e, cpu).l1); /* Confirm these have been cached. */ + l1e_write(pv_gdt_ptes(v) + FIRST_RESERVED_GDT_PAGE, !is_pv_32bit_vcpu(v) ? per_cpu(gdt_l1e, cpu) : per_cpu(compat_gdt_l1e, cpu)); diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c index 961bdf53331c..491cbbba33ae 100644 --- a/xen/arch/x86/smpboot.c +++ b/xen/arch/x86/smpboot.c @@ -1167,6 +1167,17 @@ void __init smp_prepare_cpus(void) initialize_cpu_data(0); /* Final full version of the data */ print_cpu_info(0); =20 + /* + * Cache {,compat_}gdt_l1e for the BSP now that physically relocation = is + * done. It must be after physical relocation of Xen, and before the + * first context_switch(). + */ + this_cpu(gdt_l1e) =3D + l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW); + if ( IS_ENABLED(CONFIG_PV32) ) + this_cpu(compat_gdt_l1e) =3D + l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_R= W); + boot_cpu_physical_apicid =3D get_apic_id(); x86_cpu_to_apicid[0] =3D boot_cpu_physical_apicid; =20 diff --git a/xen/arch/x86/traps-setup.c b/xen/arch/x86/traps-setup.c index d77be8f83921..c5fc71c75bca 100644 --- a/xen/arch/x86/traps-setup.c +++ b/xen/arch/x86/traps-setup.c @@ -341,13 +341,6 @@ void __init traps_init(void) =20 init_ler(); =20 - /* Cache {,compat_}gdt_l1e now that physically relocation is done. */ - this_cpu(gdt_l1e) =3D - l1e_from_pfn(virt_to_mfn(boot_gdt), __PAGE_HYPERVISOR_RW); - if ( IS_ENABLED(CONFIG_PV32) ) - this_cpu(compat_gdt_l1e) =3D - l1e_from_pfn(virt_to_mfn(boot_compat_gdt), __PAGE_HYPERVISOR_R= W); - percpu_traps_init(); } =20 --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234224; cv=none; d=zohomail.com; s=zohoarc; b=GIwM1wwxk21sQYK64XV9Vax8qTd6vf4UBvKA/VHaCjqBugxZ7p9cpXIJ6I1haEoWNT0h+5ivNXoqMDMSdDhVop/UMvXDwBw7p9XT7a7uIsc8TzpEJMbwc8TdZ/QJHuyIR9sDTN0sCA0e9Rc6usg49ZpoT4Qzh0maWVMQMQ/t1JY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234224; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=wSmplNXhRERAowFWA9uIl/lO9zqC+gj9SfzDfIr2SeQ=; b=Q4w5oLezXm8sKBf/XbvN4asm1GnDJu9c06XwSPwADBwnWihC2EMgqIun496ta6G04+KoBfdujSqpXAFbMXXDyp34/G5jGi9ZYncDe1cTP55FOPeI9CAJ2kcst+CHOXdW5XbxPhZxNFdIIPrpSHUYWNdQxOFjyzCpNcs4S6aQz9k= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234224509955.4046374839377; Fri, 27 Feb 2026 15:17:04 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243140.1543151 (Exim 4.92) (envelope-from ) id 1vw74k-0001Gc-Kc; Fri, 27 Feb 2026 23:16:50 +0000 Received: by outflank-mailman (output) from mailman id 1243140.1543151; Fri, 27 Feb 2026 23:16:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74k-0001GV-Hi; Fri, 27 Feb 2026 23:16:50 +0000 Received: by outflank-mailman (input) for mailman id 1243140; Fri, 27 Feb 2026 23:16:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74j-0001Do-As for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:49 +0000 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [2a00:1450:4864:20::435]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 632ad0ca-1432-11f1-9ccf-f158ae23cfc8; Sat, 28 Feb 2026 00:16:47 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-436309f1ad7so2114610f8f.3 for ; Fri, 27 Feb 2026 15:16:47 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:44 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 632ad0ca-1432-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234206; x=1772839006; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wSmplNXhRERAowFWA9uIl/lO9zqC+gj9SfzDfIr2SeQ=; b=m6m+SJal6DBgyMJkYVtOAxLZPkvazgIJsWlBSfD+IBqJFMxDe8RG3dD1yy0wd+kEx7 M4+xbVDm0LyCHxDcM6Slf9g6czWs0BTWw13nq01VIP8Hxe7ScCVNj9hO+Pb8KYYvPAKM Fae7CLq/CcQl2z9afMzxZ/Py8bVwWf31FwI88= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234206; x=1772839006; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=wSmplNXhRERAowFWA9uIl/lO9zqC+gj9SfzDfIr2SeQ=; b=kGH5puSBtS8f2byRD3uedhh2g2Jf4UlygGY81rla5GGY3C+FaTSL+UAWJXanZp042x vyCEJrCqWGjSJ/R0d5vQmFo1KE23ofeRFd4WDyWFnJwzphCng5tRFFBXiYD2APfyNH0l 3fgCIrYdEjfeGmlllM4U4Z7JN1Spm35vQGgBYkqB25zhVawI/Rkod+gppKOiHp486KuJ 5Ebv0YaHjOa1PvFmT0qBulyzM0Pb4ACUrofeixh2MYrAaJlwQUnNwK7FiPzlZF2d0gZf llM5o1ca6H+FsPPZjmy97TzSqSs/26NrfGRzEpsLYP2stF8Ar9QzMdoQJLeGDBjQqcip aNGQ== X-Gm-Message-State: AOJu0YzU0so86jO5NdjQSfPwW9UWnIDfNZ/vhvylb1ESZaY3R74lHgWF GmzAX87BaRGeUiGsqW9uChkvx01FqL2GK8/ehtL2pmBm6XfqvDxFH3ScRPn0S8anwWoRObgdFM7 YWdlZ X-Gm-Gg: ATEYQzzAOFeCs3lTn13kaoVaZo7A/l8aCgLM2tao6krK0tFr9FiaVjfHOcZrM/AzxJh o170EqFdOnGfSc4FY/IUcTsuNUBHbn/iCQ1UgdrUEJJ/tD4+szT7JsHX+15Gdr9CQ1kCGJPVU1N C06j5gtP3tKXB9G1w/ROWyuz4b6m8gA3ULsRaTz+oz5Wt/GwWkGTfq/S0IFlgy/5xVqULJjQEkD HYbaMxpYJXwZJwKJAYYU66ki1ZDHB6YfwdQ2Mpqgctix4NRXPtbr0+LGzH7kXvvplvuA5tOqk+Y YfG2Wi7UbuYwEW6HAmzN2NmbpS1q6m8W7I2qQOOmdKNcvo0I2S7xZYiioBy0WqNg4ox6uPH77rk oX+9U9sxwrjeAHcga+wDSWnZdZE+MoizcYOfNg26ZXhk6XpIil7dU17gXbyw0SwvvJ76bPT3um7 KoBg71o3F+Xq95pTC/7A85EHshB2as1UlaMeN1z4TOLj1e0tEOLApMemD3O5Wk7EnBYLd10uQ= X-Received: by 2002:a05:6000:1447:b0:435:9e32:2b78 with SMTP id ffacd0b85a97d-4399dddbbb3mr7543711f8f.1.1772234205704; Fri, 27 Feb 2026 15:16:45 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 04/14] x86/boot: Document the ordering dependency of _svm_cpu_up() Date: Fri, 27 Feb 2026 23:16:26 +0000 Message-Id: <20260227231636.3955109-5-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234226341158500 Lets just say this took an unreasoanble amount of time and effort to track down, when trying to move traps_init() earlier during boot. When the SYSCALL linkage MSRs are not configured ahead of _svm_cpu_up() on = the BSP, the first context switch into PV uses svm_load_segs() and clobbers the later-set-up linkage with the 0's cached here, causing hypercalls issues by the PV guest to enter at 0 in supervisor mode on the user stack. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * New It occurs to me that it's not actually 0's we cache here. It's whatever context was left from prior to Xen. We still don't reliably clean unused MSRs. --- xen/arch/x86/hvm/svm/svm.c | 16 ++++++++++++++++ xen/arch/x86/setup.c | 2 +- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 18ba837738c6..f1e02d919cae 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include =20 @@ -1581,6 +1582,21 @@ static int _svm_cpu_up(bool bsp) /* Initialize OSVW bits to be used by guests */ svm_host_osvw_init(); =20 + /* + * VMSAVE writes out the current full FS, GS, LDTR and TR segments, and + * the GS_SHADOW, SYSENTER and SYSCALL linkage MSRs. + * + * The segment data gets modified by the svm_load_segs() optimisation = for + * PV context switches, but all values get reloaded at that point, as = well + * as during context switch from SVM. + * + * If PV guests are available (and FRED is not in use), it is critical + * that the SYSCALL linkage MSRs been configured at this juncture. + */ + ASSERT(opt_fred >=3D 0); /* Confirm that FRED-ness has been resolved */ + if ( IS_ENABLED(CONFIG_PV) && !opt_fred ) + ASSERT(rdmsr(MSR_LSTAR)); + svm_vmsave_pa(per_cpu(host_vmcb, cpu)); =20 return 0; diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 27c63d1d97c9..675de3a649ea 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -2078,7 +2078,7 @@ void asmlinkage __init noreturn __start_xen(void) &this_cpu(stubs).mfn); BUG_ON(!this_cpu(stubs.addr)); =20 - traps_init(); /* Needs stubs allocated. */ + traps_init(); /* Needs stubs allocated, must be before presmp_initcall= s. */ =20 cpu_init(); =20 --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234228; cv=none; d=zohomail.com; s=zohoarc; b=bMaeTzCrdsBvAJBG2BoEIq/UtJK9dulJght4x9KqENVuRsc37m7z3tE7fDd1NwSzenHwFpd4mgZ/4j8kM+r5ewyBqCnf9pXAOlwPGE16028lDDDQInZ+ir/1XIq3M9fR8Mlu2hb0xoMSamsTvk+riJypgIK6Zo511ucWH7gXWOU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234228; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=vW+QCUaUYuUq9G8gsk0OzquSefAutMzWyPSfjvJkvyY=; b=e4jOndW0Db7V8bYPqHirD9UEtXDeQd+hWtmHEwujEsJXALxWYKzl3c16kHISMnuU2vHtda++TdhGjYWv6+TTxIr3yV27TNMC7Qo6Q9nQh8gGW9oeJDTH0KbUk8lz/GBlumWk59fDOEujpLfWPDwiXijsal/57UjFHxgxwamO27E= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234228087617.766815838593; Fri, 27 Feb 2026 15:17:08 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243142.1543161 (Exim 4.92) (envelope-from ) id 1vw74l-0001Vk-TD; Fri, 27 Feb 2026 23:16:51 +0000 Received: by outflank-mailman (output) from mailman id 1243142.1543161; Fri, 27 Feb 2026 23:16:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74l-0001Vd-Ou; Fri, 27 Feb 2026 23:16:51 +0000 Received: by outflank-mailman (input) for mailman id 1243142; Fri, 27 Feb 2026 23:16:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74j-0001Do-WE for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:50 +0000 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [2a00:1450:4864:20::42c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 63667f70-1432-11f1-9ccf-f158ae23cfc8; Sat, 28 Feb 2026 00:16:47 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-4377174e1ebso1836368f8f.3 for ; Fri, 27 Feb 2026 15:16:47 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:45 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 63667f70-1432-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234207; x=1772839007; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=vW+QCUaUYuUq9G8gsk0OzquSefAutMzWyPSfjvJkvyY=; b=vhLha4bonoIIVEtrCYPP1O9oG/HtAdS9glPqoD/EGaAeaM0qrSyp0hb7oBSKNSCxr2 KRSY5Z1dC4Xef20vDJo01G75YjPd8nLXjstEHDXml7wO7nRDcdxODY3UgTvjDCuwwFLW iDDmo7htP/Mp+Ob60RpxIlNP54a/Ft1pu3RKM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234207; x=1772839007; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=vW+QCUaUYuUq9G8gsk0OzquSefAutMzWyPSfjvJkvyY=; b=Zzb6OjewaZBPMNFP4yyG4zRagBGyDLHRiZH+kU8H0a1ZZFJT1su8sOEPgGqF3Xkab+ xKVcOnURpeL2CRA1IRy49nKQZUbXWynSPRzisfbWZkqNUEXdF+SyaGhIJ9uv2eOwYFSU r+smbv4RG7+89alOMtK807xyaTm+pa6/TOwQjGvehB/54gIuZlOmuT7Jo7+5Xx1sVrzr 9QTrzy6z5ebOtFIdkb4Tlayh0+YpeBgP/9Nlp3GIrmsFpW+RpNeAMu1oRqjCZh4EupEV K1dY2E3IX9JmE6IO+DNKdAxirKLaHaf6Htwapa94+HLHbDjZvc+jR33DeAWxJmah6/lN 7sqQ== X-Gm-Message-State: AOJu0YzF0KyY8nDaaI8mPnMXdz0sjnr/xuOJSXZdvLYhJSe6iMRlsoZg 8Hqq466CnoaQPy833cIqJjoTlmkLn5d55a+p3LIjZrvokpp/ZPwYmx7kqSKhf4xbecBPlUpuSlj m56CTSJzVEQ== X-Gm-Gg: ATEYQzyOh+nZyZYUl+Oxb5m9gLnnvQ77+8+JLKCIDIOOG75jmX6c3c2Hny4bRsLsSID HTqm78aNhITRpVNnVF68OYTWjb8ttQNc5KFams6hw2dBiHL8hNSx4hVun2BaG361X9vmgX6gWw3 pc9oJu7k06bTSUMI7pgGL5drJZ7oEi4BAAcEN+/025FEN+xOs1e40Yx5eDlx4xy6ZseMbwH3MmL I4Qm5hpK/BEpab3zDC7AqBkJkgWYeaDzqTmUW6M11lc8Iv3F5XDciEjoeZh1XzwFTXqQzLDSAt2 j/hDv9SCfyvO2dm6J2GqyawyVp6iCPYRfIfIlmxOP4R2TFMCnji9oMinnZz4GbrncF0svUK5Cv3 nM2dfT24ZKjJecfOe2TJLHcRQD1TRbOxwHP10SgFf9F/Y6uhgtBW5au+rIZBaB/q8zZBA7nV19l uiUXPAw8wWXt6NpPm8FvK/CauML9WWnS1R1LxyzTUfgW+HtUgzDyKXG/JkJtVFlW2lXS/AI4g= X-Received: by 2002:a05:6000:2483:b0:439:5bfe:18ce with SMTP id ffacd0b85a97d-4399dde22d3mr8576771f8f.8.1772234206354; Fri, 27 Feb 2026 15:16:46 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 05/14] x86/traps: Move traps_init() earlier on boot Date: Fri, 27 Feb 2026 23:16:27 +0000 Message-Id: <20260227231636.3955109-6-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234246260158500 We wish to make use of opt_fred earlier on boot, which involves moving traps_init() earlier, but this comes with several ordering complications. The feature word containing FRED needs collecting in early_cpu_init(), and legacy_syscall_init() cannot be called that early because it relies on the stubs being allocated, yet must be called ahead of cpu_init() so the SYSCALL linkage MSRs are set up before being cached. Delaying legacy_syscall_init() is easy enough based on a system_state check. Reuse bsp_traps_reinit() to cause a call to legacy_syscall_init() to occur = at the same point as previously. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * New I don't particualrly like this solution, but the layout of these functions change for FRED. Any adjustments need to consider the logic at the end of = the series, not at this point. --- xen/arch/x86/cpu/common.c | 4 +++- xen/arch/x86/setup.c | 4 +++- xen/arch/x86/traps-setup.c | 12 +++++++++++- 3 files changed, 17 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index bfa63fcfb721..5d0523a78b52 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -407,7 +407,9 @@ void __init early_cpu_init(bool verbose) } =20 if (max_subleaf >=3D 1) - cpuid_count(7, 1, &eax, &ebx, &ecx, + cpuid_count(7, 1, + &c->x86_capability[FEATURESET_7a1], + &ebx, &ecx, &c->x86_capability[FEATURESET_7d1]); } =20 diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 675de3a649ea..0816a713e1c8 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1386,6 +1386,8 @@ void asmlinkage __init noreturn __start_xen(void) else panic("Bootloader provided no memory information\n"); =20 + traps_init(); + /* Choose shadow stack early, to set infrastructure up appropriately. = */ if ( !boot_cpu_has(X86_FEATURE_CET_SS) ) opt_xen_shstk =3D 0; @@ -2078,7 +2080,7 @@ void asmlinkage __init noreturn __start_xen(void) &this_cpu(stubs).mfn); BUG_ON(!this_cpu(stubs.addr)); =20 - traps_init(); /* Needs stubs allocated, must be before presmp_initcall= s. */ + bsp_traps_reinit(); /* Needs stubs allocated, must be before presmp_in= itcalls. */ =20 cpu_init(); =20 diff --git a/xen/arch/x86/traps-setup.c b/xen/arch/x86/traps-setup.c index c5fc71c75bca..b2c161943d1e 100644 --- a/xen/arch/x86/traps-setup.c +++ b/xen/arch/x86/traps-setup.c @@ -346,6 +346,10 @@ void __init traps_init(void) =20 /* * Re-initialise all state referencing the early-boot stack. + * + * This is called twice during boot, first to ensure legacy_syscall_init()= has + * run (deferred from earlier), and second when the virtual address of the= BSP + * stack changes. */ void __init bsp_traps_reinit(void) { @@ -359,7 +363,13 @@ void __init bsp_traps_reinit(void) */ void percpu_traps_init(void) { - legacy_syscall_init(); + /* + * Skip legacy_syscall_init() at early boot. It requires the stubs be= ing + * allocated, limiting the placement of the traps_init() call, and gets + * re-done anyway by bsp_traps_reinit(). + */ + if ( system_state > SYS_STATE_early_boot ) + legacy_syscall_init(); =20 if ( cpu_has_xen_lbr ) wrmsrl(MSR_IA32_DEBUGCTLMSR, IA32_DEBUGCTLMSR_LBR); --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234229; cv=none; d=zohomail.com; s=zohoarc; b=Fa5N6Ub8/mLWvm/U8RxZpjDKE48kDRrRJvYuFTechSW1eRtCpgPVUoth+IVL4IFlJnTAGhh0QnslO0K2inVVwZU5UulQ68cElhEG7bW+hpdOkfy5/vB73+nnBWGgitHwAH3mV+RrgWZYyFJIZAbebA2idWkibtMaF++yMogT8Zg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234229; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=0CZO8VvFJTkoemSFkzFWEvoCyFq1y2gQ5xOPrI9dn3A=; b=gEmdwOkSsKC1dWu8zQe1aWr83EP8xPQ/bFPch5EcXtK2Lt7Pc3tuTbJEvt54CXx5RRuM0OVXEOYmp2Xueiw3viE6XaidTgem2zMp7U/4ORnXcPo0ITU7nDVpypuyeXy4hGRexdEcf4AoMYgznqVPQhXFXaxpfvL7CM5+AN8KQsU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234229911971.9572442289502; Fri, 27 Feb 2026 15:17:09 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243146.1543189 (Exim 4.92) (envelope-from ) id 1vw74o-00029Q-4i; Fri, 27 Feb 2026 23:16:54 +0000 Received: by outflank-mailman (output) from mailman id 1243146.1543189; Fri, 27 Feb 2026 23:16:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74n-00029E-W6; Fri, 27 Feb 2026 23:16:53 +0000 Received: by outflank-mailman (input) for mailman id 1243146; Fri, 27 Feb 2026 23:16:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74m-0001Do-0J for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:52 +0000 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [2a00:1450:4864:20::42b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 641b136d-1432-11f1-9ccf-f158ae23cfc8; Sat, 28 Feb 2026 00:16:48 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-43994aa265eso1501203f8f.3 for ; Fri, 27 Feb 2026 15:16:48 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:46 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 641b136d-1432-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234208; x=1772839008; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0CZO8VvFJTkoemSFkzFWEvoCyFq1y2gQ5xOPrI9dn3A=; b=dweHs6CDlyA5ruvLcqqzr5Zu5mYbhtimbFNBp2lpIBiMIXDjKa7DrsopvcWKSNt2lH ODbWCWBzPbLkLnP/+ZcbSxAeP4MR9RN+AUjD9wX8ptpPP47f1agyFG7HI/d3j12dI/05 /EyVuvt/EA0G2i+CbYWuJVK1y9kUg3BYlAS7s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234208; x=1772839008; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0CZO8VvFJTkoemSFkzFWEvoCyFq1y2gQ5xOPrI9dn3A=; b=Tj3fXQep3FnfwEvoDFzLMI6BYuBL5xP//0wtoXcS0guckHB6nqZ7v7FM8hahGUDrhK 4ajERYCbsDAW8Mq54uwSRBvWVjNDGBN+N+oNXmUI/6ET07Bb1m4Ofy7EfP74p2e7FD3n nVrXmyGWXh/KTtrPgFoqOv82MI9lquSPH/fTHiJ+GkLgH5P5tMso9D59B+cNtJgPtNRf KJ5oV0eq2TqqLzInPi30h4V48G1cviONL8MhwiRs6Mlm0/3uCM5Nf5hXc73h8/5a30fE BijuHCnO7qOP5iSHUC9XydYJFPC9MLyNAZGCL/rZYGqFakLrNwbdch9POW770QHILRRq IYTw== X-Gm-Message-State: AOJu0YxKO9McFlP/WRhAsEPQWKY+0J2jfjotLVqJ4LwqgUyXhRIy7Iqw OVULngWr9lUSRMXWSmOx2Ra8ArYMn1vIjy/HPKm8NxK+ZnTge0gK5lgx/M5LGYSujlxjdF5Z+HV MyPfT X-Gm-Gg: ATEYQzxij0quOpjKrHY/jT0jQUkNrDLuUECa1kNEY2eNmdUm/dLOtcuDZDt+dL4FO0u 2ieoeIKaKY41qfhogoKpvOwDXGIlg9cMonogHQcjqEe3LDwKBgYn/OFiPoBu90OzjuaUJ2uHhm+ 7BgBeL/nRckCiCmAaGFjgNOnvfOH2y6dg3+P3fNfu3rHJ2RklguTBw+XUihBVbe5salxZ0mNtzH WPvBmfcb1aVyYUBwb7ZYiJS4SXvDbwNkiQorGv1ooQbLZEJd6CHoMiViBPh6kLW02OeuLibldLa ZVNHvwWK/SxEoHRfdpk8IjEyAPBUuUc9unOLeWeGg/6pLUoz1VBJUfNKaMZ2IKiCi48bURgmVXC alurzysNBTq4xdAV5cEMJPF0xcU0CeSQBXJP+M3svVNpqWYd6T2VpCuCuAOCSUHvbD0DEWRoE51 g62Yx6UYZrIoSY0GgVBnbiM5L/0yblNtJeReR52pHQDfc/1LkruyxFLKTWXMbEutOQy35HVJo= X-Received: by 2002:a05:6000:18a9:b0:439:8e2f:689e with SMTP id ffacd0b85a97d-4399de2c5demr7687079f8f.43.1772234207185; Fri, 27 Feb 2026 15:16:47 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 06/14] x86/traps: Don't configure Supervisor Shadow Stack tokens in FRED mode Date: Fri, 27 Feb 2026 23:16:28 +0000 Message-Id: <20260227231636.3955109-7-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234230457158500 FRED doesn't use Supervisor Shadow Stack tokens. This means that: 1) memguard_guard_stack() should not write Supervisor Shadow Stack Tokens. 2) cpu_has_bug_shstk_fracture is no longer relevant when deciding whether = or not to enable Shadow Stacks in the first place. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * Adjust for cpu_has_bug_shstk_fracture. * Reworked entirely in light of the prior 3 patches. The SDM explicitly points out the shstk fracture vs FRED case, yet PTL enumerates CET-SSS (immunity to shstk fracture). I can only assume that th= ere are other Intel CPUs with FRED but without CET-SSS. --- xen/arch/x86/mm.c | 14 +++++++++++--- xen/arch/x86/setup.c | 16 ++++++++++------ 2 files changed, 21 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 0d0d5292953b..4c404b6c134f 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -129,6 +129,7 @@ #include #include #include +#include #include =20 #include @@ -6441,8 +6442,15 @@ static void write_sss_token(unsigned long *ptr) =20 void memguard_guard_stack(void *p) { - /* IST Shadow stacks. 4x 1k in stack page 0. */ - if ( IS_ENABLED(CONFIG_XEN_SHSTK) ) + ASSERT(opt_fred >=3D 0); /* Confirm that FRED-ness has been resolved */ + + /* + * IST Shadow stacks. 4x 1k in stack page 0. + * + * With IDT delivery, we need Supervisor Shadow Stack tokens at the ba= se + * of each stack. With FRED delivery, these no longer exist. + */ + if ( IS_ENABLED(CONFIG_XEN_SHSTK) && !opt_fred ) { write_sss_token(p + (IST_MCE * IST_SHSTK_SIZE) - 8); write_sss_token(p + (IST_NMI * IST_SHSTK_SIZE) - 8); @@ -6453,7 +6461,7 @@ void memguard_guard_stack(void *p) =20 /* Primary Shadow Stack. 1x 4k in stack page 5. */ p +=3D PRIMARY_SHSTK_SLOT * PAGE_SIZE; - if ( IS_ENABLED(CONFIG_XEN_SHSTK) ) + if ( IS_ENABLED(CONFIG_XEN_SHSTK) && !opt_fred ) write_sss_token(p + PAGE_SIZE - 8); =20 map_pages_to_xen((unsigned long)p, virt_to_mfn(p), 1, PAGE_HYPERVISOR_= SHSTK); diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 0816a713e1c8..8e59c9801afe 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1412,15 +1412,19 @@ void asmlinkage __init noreturn __start_xen(void) boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL && !boot_cpu_has(X86_FEATURE_CET_SSS); =20 + ASSERT(opt_fred >=3D 0); /* Confirm that FRED-ness has been resolv= ed */ + /* - * On bare metal, assume that Xen won't be impacted by shstk - * fracturing problems. Under virt, be more conservative and disa= ble - * shstk by default. + * If FRED is in use, Supervisor Shadow Stack tokens are not used = and + * shstk fracturing is of no consequence. Otherwise: + * - On bare metal, assume that Xen won't be impacted by shstk + * fracturing problems. + * - Under virt, be more conservative and disable shstk by default. */ if ( opt_xen_shstk =3D=3D -1 ) opt_xen_shstk =3D - cpu_has_hypervisor ? !cpu_has_bug_shstk_fracture - : true; + opt_fred || (cpu_has_hypervisor ? !cpu_has_bug_shstk_fract= ure + : true); =20 if ( opt_xen_shstk ) { @@ -1925,7 +1929,7 @@ void asmlinkage __init noreturn __start_xen(void) =20 system_state =3D SYS_STATE_boot; =20 - bsp_stack =3D cpu_alloc_stack(0); + bsp_stack =3D cpu_alloc_stack(0); /* Needs to know IDT vs FRED */ if ( !bsp_stack ) panic("No memory for BSP stack\n"); =20 --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234230; cv=none; d=zohomail.com; s=zohoarc; b=l+UKBd+MKw1Gr4F/Z+heCVX6Tzed3M8hqQlNg3t29IMYvUvJir2uNigBwuF3eK2zxqsgAd/lxSKksGHpiwTYV5ET6EngpYCOFmhM94UpK8jFiLWP8YcMsj45qG61Kvfy4aHFQySJ45awop1V3FNHboj7H8Qse4wmVKzTaVMYs5Y= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234230; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=0UFkS5LRVpmC0KP6ipyZ4ETPBXtVQAe04/RvjF0fewY=; b=LLmWskcuDgdW9BCK/jHtQ0XcZDGSozSnsGA4Kts4nHAKBOQDbbvqwDOBvDVj/DlWrCBkjqInwF/ROEjoRRZeqrGOLCRRlBnMWESjeI7e9gahRqRZgkZcso6z0IjjgANzS8Ncl9JT84+Ul+SY4Gnj+ajydi+ObMwzlS3h/zjN7ZY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234230123319.457171190013; Fri, 27 Feb 2026 15:17:10 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243143.1543166 (Exim 4.92) (envelope-from ) id 1vw74m-0001ZB-95; Fri, 27 Feb 2026 23:16:52 +0000 Received: by outflank-mailman (output) from mailman id 1243143.1543166; Fri, 27 Feb 2026 23:16:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74m-0001Xx-1i; Fri, 27 Feb 2026 23:16:52 +0000 Received: by outflank-mailman (input) for mailman id 1243143; Fri, 27 Feb 2026 23:16:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74k-0008WD-Eh for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:50 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 64a23d16-1432-11f1-b164-2bf370ae4941; Sat, 28 Feb 2026 00:16:49 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-436e87589e8so2508815f8f.3 for ; Fri, 27 Feb 2026 15:16:49 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:47 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 64a23d16-1432-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234209; x=1772839009; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0UFkS5LRVpmC0KP6ipyZ4ETPBXtVQAe04/RvjF0fewY=; b=Cvna4BAnfjmVea8EYBguec/SIJ54FYSiFw6gdPhB6LP5SVDRKl+kmXZ3exQly+xriw cTFSYfL2qDqJgsElxix0kL+m6gvUSbCe89WM2O5PwSfpggfnocBJhTUJMLdmA7z9rOek 25pasuPJHgclQSOB+OBawF0VbaYHxv6X4KcC8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234209; x=1772839009; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0UFkS5LRVpmC0KP6ipyZ4ETPBXtVQAe04/RvjF0fewY=; b=nVqmpVHGilYf1jrojZoJ2589McoZe7sH64MO8Z0K8QuPoByNkKF/x6MqNO9iV94fzf WD1b/5z1cPaEXNmzRCsAQRtMlaMNJa8uFBXigrfAbDTi8hryrxlj8d7Ltt+MqyNY9djF BzfWMkUc3mBiaP9hq05wwhPylYdy2WDcpQzPd48m2dCgd5UDEXGvK6ecH2uvLaSPMgg0 j/NFoLh8So51kNxOVDeQetYTzgjw7wqZNR87zWaHZRwSazK2tVSKkLij6gZkF37KBlvu FImyb9aribDSlBSiMUtKjR9qRBz9JYzJxSDD0lOvJbC03gY4lWMhmNFD6tcym8GZMju+ Od4w== X-Gm-Message-State: AOJu0YzAnf85+91Sc+RYZIcquMot2Iie//pG/KzDg02HqxQas8+KGoqO dX0sPtZwtzePEI/NA72rnjmOrXjEK7dHjQSZjSojgH0DNql0ZeRekrwRsyi3MhwN/t58Ds45dgD CJJUq X-Gm-Gg: ATEYQzxU1CBRfw8h1JkqvHqijWhpiEwMHrN/0YLOipz5qJAchjonktSzeHRtONU+fM2 Xs3ybIK8mbREjtJwBAqJXiBpVXMaD8LQexwLKEYxIZuPUXohaJihcGYN3QukG62kVVz61kN3rfU w+pkQb6dp7L2VuSCT9kgeZIdxb5XM9Qk1jTeop0oERZ+JJUYz54DegRoCMMUcRM5C0Vv0ncivVN aJQmQ0uyvI8G2fiqkfT4k1YZTXVNSRBSN/YqvVJx1NkSfMm7t/6LCHIiTDbT9adokvmiKg9wxCS e4YJbhruJOgFNTAQIOdMEPF+iiwYdpysWae0JkV6D/vDR7b2rXZJazEXYdvcVp8BoD9wRX47b7B eQJkhCVvfmyPfRoGFFAD9HIPVZw5dkt/hjctyZcVTACZbZWY2p8KxbBMclfVjEICfxoClp3CNfn 0Q6Ihyn15F1HhrMPJAreIQTYzwoqHwfpgj/xuvOjCQJC/AxG4OlQnVF80wtbJzh8SafbQ+hFtJB vic/qbPMw== X-Received: by 2002:a5d:5f94:0:b0:435:9144:1417 with SMTP id ffacd0b85a97d-4399de2baacmr8254016f8f.49.1772234208054; Fri, 27 Feb 2026 15:16:48 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 07/14] x86/traps: Introduce FRED entrypoints Date: Fri, 27 Feb 2026 23:16:29 +0000 Message-Id: <20260227231636.3955109-8-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234230510158500 Under FRED, there's one entrypoint from Ring 3, and one from Ring 0. FRED gives us a good stack (even for SYSCALL/SYSENTER), and a unified event frame on the stack, meaing that all software needs to do is spill the GPRs with a line of PUSHes. Introduce PUSH_AND_CLEAR_GPRS for this purpose, alo= ng with the matching POP_GPRS. Introduce entry_FRED_R0() which to a first appoximation is complete for all event handling within Xen. entry_FRED_R0() needs deriving from entry_FRED_R3(), so introduce a basic handler. There is more work required to make the return-to-guest path work under FRED. Also introduce entry_from_{xen,pv}() to be the C level handlers. By simply copying regs->fred_ss.vector into regs->entry_vector, we can reuse all the existing fault handlers. Extend fatal_trap() to render the event type, including by name, when FRED = is active. This is slightly complicated, because X86_ET_OTHER must not use vector_name() or SYSCALL and SYSENTER get rendered as #BP and #DB. This is sufficient to handle all interrupts and exceptions encountered duri= ng development, including plenty of Double Faults. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * Drop POP_GPRS %rax parameter for now. * Treat nested events as fatal. Even if the condition didn't escalate to #DF, it still indicates an error with the linkage setup. v3: * Adjust commit message to remove stale details * Adjust formatting in fatal_trap() * Group CP with others. It's probably wrong for perf, but that's out the window anyway now that we're letting a compiler make the decision tree. v2: * Don't render a vector name for X86_ET_SW_INT * Fix typos in names[] * Link entry-fred.o first SIMICS hasn't been updated to the FRED v9, and still wants ENDBR instructio= ns at the entrypoints. --- xen/arch/x86/include/asm/asm_defns.h | 63 +++++++++++ xen/arch/x86/traps.c | 155 +++++++++++++++++++++++++++ xen/arch/x86/x86_64/Makefile | 1 + xen/arch/x86/x86_64/entry-fred.S | 33 ++++++ 4 files changed, 252 insertions(+) create mode 100644 xen/arch/x86/x86_64/entry-fred.S diff --git a/xen/arch/x86/include/asm/asm_defns.h b/xen/arch/x86/include/as= m/asm_defns.h index 4a21a7b46684..0dd63270fc7c 100644 --- a/xen/arch/x86/include/asm/asm_defns.h +++ b/xen/arch/x86/include/asm/asm_defns.h @@ -312,6 +312,69 @@ static always_inline void stac(void) subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp .endm =20 +/* + * Push and clear GPRs + */ +.macro PUSH_AND_CLEAR_GPRS + push %rdi + xor %edi, %edi + push %rsi + xor %esi, %esi + push %rdx + xor %edx, %edx + push %rcx + xor %ecx, %ecx + push %rax + xor %eax, %eax + push %r8 + xor %r8d, %r8d + push %r9 + xor %r9d, %r9d + push %r10 + xor %r10d, %r10d + push %r11 + xor %r11d, %r11d + push %rbx + xor %ebx, %ebx + push %rbp +#ifdef CONFIG_FRAME_POINTER +/* Indicate special exception stack frame by inverting the frame pointer. = */ + mov %rsp, %rbp + not %rbp +#else + xor %ebp, %ebp +#endif + push %r12 + xor %r12d, %r12d + push %r13 + xor %r13d, %r13d + push %r14 + xor %r14d, %r14d + push %r15 + xor %r15d, %r15d +.endm + +/* + * POP GPRs from a UREGS_* frame on the stack. Does not modify flags. + */ +.macro POP_GPRS + pop %r15 + pop %r14 + pop %r13 + pop %r12 + pop %rbp + pop %rbx + pop %r11 + pop %r10 + pop %r9 + pop %r8 + pop %rax + pop %rcx + pop %rdx + pop %rsi + pop %rdi +.endm + #ifdef CONFIG_PV32 #define CR4_PV32_RESTORE \ ALTERNATIVE_2 "", \ diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 907fb4c186c0..48667c71d591 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -88,6 +88,13 @@ const unsigned int nmi_cpu; #define stack_words_per_line 4 #define ESP_BEFORE_EXCEPTION(regs) ((unsigned long *)(regs)->rsp) =20 +/* Only valid to use when FRED is active. */ +static inline struct fred_info *cpu_regs_fred_info(struct cpu_user_regs *r= egs) +{ + ASSERT(read_cr4() & X86_CR4_FRED); + return &container_of(regs, struct cpu_info, guest_cpu_user_regs)->_fre= d; +} + struct extra_state { unsigned long cr0, cr2, cr3, cr4; @@ -1028,6 +1035,32 @@ void show_execution_state_nmi(const cpumask_t *mask,= bool show_all) printk("Non-responding CPUs: {%*pbl}\n", CPUMASK_PR(&show_state_ma= sk)); } =20 +static const char *x86_et_name(unsigned int type) +{ + static const char *const names[] =3D { + [X86_ET_EXT_INTR] =3D "EXT_INTR", + [X86_ET_NMI] =3D "NMI", + [X86_ET_HW_EXC] =3D "HW_EXC", + [X86_ET_SW_INT] =3D "SW_INT", + [X86_ET_PRIV_SW_EXC] =3D "PRIV_SW_EXC", + [X86_ET_SW_EXC] =3D "SW_EXC", + [X86_ET_OTHER] =3D "OTHER", + }; + + return (type < ARRAY_SIZE(names) && names[type]) ? names[type] : "???"; +} + +static const char *x86_et_other_name(unsigned int what) +{ + static const char *const names[] =3D { + [0] =3D "MTF", + [1] =3D "SYSCALL", + [2] =3D "SYSENTER", + }; + + return (what < ARRAY_SIZE(names) && names[what]) ? names[what] : "???"; +} + const char *vector_name(unsigned int vec) { static const char names[][4] =3D { @@ -1106,6 +1139,38 @@ void fatal_trap(const struct cpu_user_regs *regs, bo= ol show_remote) } } =20 + if ( read_cr4() & X86_CR4_FRED ) + { + bool render_ec =3D false; + const char *vec_name =3D NULL; + + switch ( regs->fred_ss.type ) + { + case X86_ET_HW_EXC: + case X86_ET_PRIV_SW_EXC: + case X86_ET_SW_EXC: + render_ec =3D true; + vec_name =3D vector_name(regs->fred_ss.vector); + break; + + case X86_ET_OTHER: + vec_name =3D x86_et_other_name(regs->fred_ss.vector); + break; + } + + if ( render_ec ) + panic("FATAL TRAP: type %u, %s, vec %u, %s[%04x]%s\n", + regs->fred_ss.type, x86_et_name(regs->fred_ss.type), + regs->fred_ss.vector, vec_name ?: "", + regs->error_code, + (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CON= TEXT"); + else + panic("FATAL TRAP: type %u, %s, vec %u, %s%s\n", + regs->fred_ss.type, x86_et_name(regs->fred_ss.type), + regs->fred_ss.vector, vec_name ?: "", + (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CON= TEXT"); + } + panic("FATAL TRAP: vec %u, %s[%04x]%s\n", trapnr, vector_name(trapnr), regs->error_code, (regs->eflags & X86_EFLAGS_IF) ? "" : " IN INTERRUPT CONTEXT"); @@ -2199,6 +2264,96 @@ void asmlinkage check_ist_exit(const struct cpu_user= _regs *regs, bool ist_exit) } #endif =20 +void asmlinkage entry_from_pv(struct cpu_user_regs *regs) +{ + /* Copy fred_ss.vector into entry_vector as IDT delivery would have do= ne. */ + regs->entry_vector =3D regs->fred_ss.vector; + + fatal_trap(regs, false); +} + +void asmlinkage entry_from_xen(struct cpu_user_regs *regs) +{ + struct fred_info *fi =3D cpu_regs_fred_info(regs); + uint8_t type =3D regs->fred_ss.type; + + /* Copy fred_ss.vector into entry_vector as IDT delivery would have do= ne. */ + regs->entry_vector =3D regs->fred_ss.vector; + + /* + * First, handle the asynchronous or fatal events. These are either + * unrelated to the interrupted context, or may not have valid context + * recorded, and all have special rules on how/whether to re-enable IR= Qs. + */ + if ( regs->fred_ss.nested ) + goto fatal; + + switch ( type ) + { + case X86_ET_EXT_INTR: + return do_IRQ(regs); + + case X86_ET_NMI: + return do_nmi(regs); + + case X86_ET_HW_EXC: + switch ( regs->fred_ss.vector ) + { + case X86_EXC_DF: return do_double_fault(regs); + case X86_EXC_MC: return do_machine_check(regs); + } + break; + } + + /* + * With the asynchronous events handled, what remains are the synchron= ous + * ones. If we interrupted an IRQs-on region, we should re-enable IRQs + * now; for #PF and #DB, %cr2 and PENDING_DBG are on the stack in edat= a. + */ + if ( regs->eflags & X86_EFLAGS_IF ) + local_irq_enable(); + + switch ( type ) + { + case X86_ET_HW_EXC: + case X86_ET_PRIV_SW_EXC: + case X86_ET_SW_EXC: + switch ( regs->fred_ss.vector ) + { + case X86_EXC_PF: handle_PF(regs, fi->edata); break; + case X86_EXC_GP: do_general_protection(regs); break; + case X86_EXC_UD: do_invalid_op(regs); break; + case X86_EXC_NM: do_device_not_available(regs); break; + case X86_EXC_BP: do_int3(regs); break; + case X86_EXC_DB: handle_DB(regs, fi->edata); break; + case X86_EXC_CP: do_entry_CP(regs); break; + + case X86_EXC_DE: + case X86_EXC_OF: + case X86_EXC_BR: + case X86_EXC_NP: + case X86_EXC_SS: + case X86_EXC_MF: + case X86_EXC_AC: + case X86_EXC_XM: + do_trap(regs); + break; + + default: + goto fatal; + } + break; + + default: + goto fatal; + } + + return; + + fatal: + fatal_trap(regs, false); +} + /* * Local variables: * mode: C diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile index f20763088740..c0a0b6603221 100644 --- a/xen/arch/x86/x86_64/Makefile +++ b/xen/arch/x86/x86_64/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_PV32) +=3D compat/ =20 +obj-bin-y +=3D entry-fred.o obj-bin-y +=3D entry.o obj-$(CONFIG_KEXEC) +=3D machine_kexec.o obj-y +=3D pci.o diff --git a/xen/arch/x86/x86_64/entry-fred.S b/xen/arch/x86/x86_64/entry-f= red.S new file mode 100644 index 000000000000..3c3320df22cb --- /dev/null +++ b/xen/arch/x86/x86_64/entry-fred.S @@ -0,0 +1,33 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + + .file "x86_64/entry-fred.S" + +#include +#include + + .section .text.entry, "ax", @progbits + + /* The Ring3 entry point is required to be 4k aligned. */ + +FUNC(entry_FRED_R3, 4096) + PUSH_AND_CLEAR_GPRS + + mov %rsp, %rdi + call entry_from_pv + + POP_GPRS + eretu +END(entry_FRED_R3) + + /* The Ring0 entrypoint is at Ring3 + 0x100. */ + .org entry_FRED_R3 + 0x100, 0xcc + +FUNC_LOCAL(entry_FRED_R0, 0) + PUSH_AND_CLEAR_GPRS + + mov %rsp, %rdi + call entry_from_xen + + POP_GPRS + erets +END(entry_FRED_R0) --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234233; cv=none; d=zohomail.com; s=zohoarc; b=Dp0bmlGazRbus9YsgpssUBb0SheqHZx+It708ROUTQ+HvMuIRIpAF2WCqqo6kLPnmkhf3qEjiIKogM1A5ivP7h9XBfKp1KSMSqn2uzGld37cIsA1d0Y82yW2eQelsA9UWS/ewvK6O5lrCmSt7yGHAkE7VXNxP43u5MOTjByCOkc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234233; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=RbhT0QMKBr/TIGT+bhPKLxd4WsrkmIxt58Vxe9HNu08=; b=b7ktmTmxQS5mYX2AlxatM0XlH6Xd7grHMKsZ1NzPV1OddKKH9N2SF7W7NiR85ahKY4WsG0dcMaadkSyfwa/Nf+mV3eoMKrpKxrdZ3eMbh2O6LoDDMzlgRFrHR65zBM0LYGLjMemjabIXYV33/NOKYfiwNHBOAjIMwbg+8x3/phA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234233861909.7578234156841; Fri, 27 Feb 2026 15:17:13 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243145.1543172 (Exim 4.92) (envelope-from ) id 1vw74m-0001iR-Px; Fri, 27 Feb 2026 23:16:52 +0000 Received: by outflank-mailman (output) from mailman id 1243145.1543172; Fri, 27 Feb 2026 23:16:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74m-0001gJ-Ky; Fri, 27 Feb 2026 23:16:52 +0000 Received: by outflank-mailman (input) for mailman id 1243145; Fri, 27 Feb 2026 23:16:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74l-0008WD-7O for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:51 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 64ee25d6-1432-11f1-b164-2bf370ae4941; Sat, 28 Feb 2026 00:16:50 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-48329eb96a7so19849895e9.3 for ; Fri, 27 Feb 2026 15:16:50 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:48 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 64ee25d6-1432-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234209; x=1772839009; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RbhT0QMKBr/TIGT+bhPKLxd4WsrkmIxt58Vxe9HNu08=; b=IqrRAk+QEM+BsjGUr+SQuBK4HVBy4xKrkt8t2aFjS8rGbBZfBhcBxGEaarc3rAvwE0 cvu2TTH7Bk3Yqz9101oIiBXFQIqemOqEMALQCoiF3yFSPQRui2F79lmOTnvJJZxy0nPl vf3JKBXrDO7B9GeJa5QjU2UkhprnmWYuCrSXw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234209; x=1772839009; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=RbhT0QMKBr/TIGT+bhPKLxd4WsrkmIxt58Vxe9HNu08=; b=lA2IouDxFj5W0swSbIGxtrWeUYl2EPNNmrNQOAUVanUYIjjoVNgNjpsdap/O9yXuPN 2TPlCAAso3gjkGQIKemi9mDX6ANi6Lw+69+/Eyn6O38wZYtNG24C+aZIlX/v9abl/LXy zMa+6M2YoO1ZVi/Nc09LKNJcFtDkb+SUkI7GGoR4UIR3KQiFtXfj5fndF3XBqXUois6o Y/w1Zjqv3QmTCdc51k0HQkwnR/R7GxVckQ9RNvr7Cu/wSrrOu1iG6AFbcdl+YtXBhoKn ih0N8t+Fe260ryBJSHiX3QFYBT/LvTqzF6vLzaasNgjvnV1sCsGGWiZUshRCDnKiw/SA 9sJQ== X-Gm-Message-State: AOJu0YzHfQSt0GgEzTxmecBN3Up+HCrpitlJpCfa8PkInsn7S5fWPwpi 3Qw1BUX6AHxoM19WBsnQImo++zLA4BaZcCcAQp3V6yrK7iQZKL9IsXjo5+6fQQCCj4KAajDUrId 97z4O X-Gm-Gg: ATEYQzwW9A/FBnBOgsZm08n5FDN3R/tAwbxsp5pbLPSWFR18Sm5pABjldN+/V5Cdn5m U6empophNCUzSh7lDroMg84PVvnENnUdwUU+R3wH7VzQNLyswjh3Ao4n/eBukz6UW9UsIIoqfam 5EzaZ6a3WOgT74N9iDqwZyFsCNRum5PmbxD4kikY03GVXh9WsmMNhZlUmU8/jS7f71dxTZhihZD lK4CH7BeAssJ5mJLWfvgkKd8YnlFpv6RLNYLwVw/J47VyFBCbeg2P/f2vP2In9kotHoKDYNKIjD k6xj/fhvuOAUnJycU7M1TokxmmBgVMUhAQlLy84LS88AC7Xfjaqf8NrhW/Fv2W0b4zjijd/P2VI 7Dr3Zm8KMAxpFRsJbdJxzZ/e2nEZgZjm6JIJjVWuneFCu/mDGX9+2lcFI8ytN8ii5TShQXWsM1z Eobyr55xNOAe8ws5Q2rXAqKCyiA/5w2Vj5g5DLDf3daiAn1owZjCu67KrcjTaOpDa4lkSEbog= X-Received: by 2002:a05:600c:4e56:b0:483:612d:7a9a with SMTP id 5b1f17b1804b1-483c9b68304mr84594355e9.0.1772234208709; Fri, 27 Feb 2026 15:16:48 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 08/14] x86/traps: Enable FRED when requested Date: Fri, 27 Feb 2026 23:16:30 +0000 Message-Id: <20260227231636.3955109-9-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234234362158500 With the shadow stack and exception handling adjustements in place, we can = now activate FRED when appropriate. Note that opt_fred is still disabled by default until more infrastructure is in place. Introduce init_fred() to set up all the MSRs relevant for FRED. FRED uses MSR_STAR (entries from Ring3 only), and MSR_FRED_SSP_SL0 aliases MSR_PL0_SSP when CET-SS is active. Otherwise, they're all new MSRs. Also introduce init_fred_tss(). At this juncture we need a TSS set up, even if it is mostly unused. Reinsert the BUILD_BUG_ON() checking the size of t= he TSS against 0x67, this time with a more precise comment. With init_fred() existing, load_system_tables() and legacy_syscall_init() should only be used when setting up IDT delivery. Insert ASSERT()s to this effect, and adjust the various init functions to make this property true. The FRED initialisation path still needs to write to all system table registers at least once, even if only to invalidate them. Per the documentation, percpu_early_traps_init() is responsible for switching off t= he boot GDT, which also needs doing even in FRED mode. Finally, set CR4.FRED in traps_init()/percpu_early_traps_init(). Xen can now boot in FRED mode and run a PVH dom0. PV guests still need more work before they can be run under FRED. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 [*] PVH Dom0 on an Intel PantherLake CPU. v4: * Rework TSS handling entirely, following the VT-x (re)discovery. v3: * Fix poisoning of SL1 pointers. * Adjust bsp_traps_reinit(). It probably doesn't matter. --- xen/arch/x86/include/asm/current.h | 3 + xen/arch/x86/include/asm/traps.h | 2 + xen/arch/x86/traps-setup.c | 130 +++++++++++++++++++++++++++-- 3 files changed, 130 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/include/asm/current.h b/xen/arch/x86/include/asm/= current.h index 62817e8476ec..6139980ab115 100644 --- a/xen/arch/x86/include/asm/current.h +++ b/xen/arch/x86/include/asm/current.h @@ -23,6 +23,9 @@ * 2 - NMI IST stack * 1 - #MC IST stack * 0 - IST Shadow Stacks (4x 1k, read-only) + * + * In FRED mode, #DB and NMI do not need special stacks, so their IST stac= ks + * are unused. */ =20 /* diff --git a/xen/arch/x86/include/asm/traps.h b/xen/arch/x86/include/asm/tr= aps.h index 73097e957d05..5d7504bc44d1 100644 --- a/xen/arch/x86/include/asm/traps.h +++ b/xen/arch/x86/include/asm/traps.h @@ -16,6 +16,8 @@ void traps_init(void); void bsp_traps_reinit(void); void percpu_traps_init(void); =20 +void nocall entry_FRED_R3(void); + extern unsigned int ler_msr; =20 const char *vector_name(unsigned int vec); diff --git a/xen/arch/x86/traps-setup.c b/xen/arch/x86/traps-setup.c index b2c161943d1e..4c8744eebe3c 100644 --- a/xen/arch/x86/traps-setup.c +++ b/xen/arch/x86/traps-setup.c @@ -59,6 +59,8 @@ static void load_system_tables(void) .limit =3D sizeof(bsp_idt) - 1, }; =20 + ASSERT(opt_fred =3D=3D 0); + /* * Set up the TSS. Warning - may be live, and the NMI/#MC must remain * valid on every instruction boundary. (Note: these are all @@ -191,6 +193,8 @@ static void legacy_syscall_init(void) unsigned char *stub_page; unsigned int offset; =20 + ASSERT(opt_fred =3D=3D 0); + /* No PV guests? No need to set up SYSCALL/SYSENTER infrastructure. */ if ( !IS_ENABLED(CONFIG_PV) ) return; @@ -268,6 +272,76 @@ static void __init init_ler(void) setup_force_cpu_cap(X86_FEATURE_XEN_LBR); } =20 +/* + * Set up all MSRs relevant for FRED event delivery. + * + * Xen does not use any of the optional config in MSR_FRED_CONFIG, so all = that + * is needed is the entrypoint. + * + * Because FRED always provides a good stack, NMI and #DB do not need any + * special treatment. Only #DF needs another stack level, and #MC for the + * offchance that Xen's main stack suffers an uncorrectable error. + * + * This makes Stack Level 1 unused, but we use #DB's stacks, and with the + * regular and shadow stacks reversed as posion to guarantee that any use + * escalates to #DF. + * + * FRED reuses MSR_STAR to provide the segment selector values to load on + * entry from Ring3. Entry from Ring0 leave %cs and %ss unmodified. + */ +static void init_fred(void) +{ + unsigned long stack_top =3D get_stack_bottom() & ~(STACK_SIZE - 1); + + ASSERT(opt_fred =3D=3D 1); + + wrmsrns(MSR_STAR, XEN_MSR_STAR); + wrmsrns(MSR_FRED_CONFIG, (unsigned long)entry_FRED_R3); + + /* + * MSR_FRED_RSP_* all come with an 64-byte alignment check, avoiding t= he + * need for an explicit BUG_ON(). + */ + wrmsrns(MSR_FRED_RSP_SL0, (unsigned long)(&get_cpu_info()->_fred + 1)); + wrmsrns(MSR_FRED_RSP_SL1, stack_top + (IST_DB * IST_SHSTK_SIZE)); /* P= oison */ + wrmsrns(MSR_FRED_RSP_SL2, stack_top + (1 + IST_MCE) * PAGE_SIZE); + wrmsrns(MSR_FRED_RSP_SL3, stack_top + (1 + IST_DF) * PAGE_SIZE); + wrmsrns(MSR_FRED_STK_LVLS, ((2UL << (X86_EXC_MC * 2)) | + (3UL << (X86_EXC_DF * 2)))); + + if ( cpu_has_xen_shstk ) + { + wrmsrns(MSR_FRED_SSP_SL0, stack_top + (PRIMARY_SHSTK_SLOT + 1) * P= AGE_SIZE); + wrmsrns(MSR_FRED_SSP_SL1, stack_top + (1 + IST_DB) * PAGE_SIZE); /= * Poison */ + wrmsrns(MSR_FRED_SSP_SL2, stack_top + (IST_MCE * IST_SHSTK_SIZE)); + wrmsrns(MSR_FRED_SSP_SL3, stack_top + (IST_DF * IST_SHSTK_SIZE)); + } +} + +/* + * Set up a minimal TSS and selector for use in FRED mode. + * + * With FRED moving the stack pointers into MSRs, we would like to avoid + * having a TSS at all, but: + * - VT-x VMExit unconditionally sets TR.limit to 0x67, meaning that + * HOST_TR_BASE needs to point to a good TSS. + * - show_stack_overflow() cross-checks tss->rsp0. + * + * Fill in rsp0 and the bitmap offset, and load a zero-length TR. If VT-x + * does get used, it will clobber TR to refer to this_cpu(tss_page).tss. + */ +static void init_fred_tss(void) +{ + seg_desc_t *gdt =3D this_cpu(gdt) - FIRST_RESERVED_GDT_ENTRY; + struct tss64 *tss =3D &this_cpu(tss_page).tss; + + tss->rsp0 =3D get_stack_bottom(); + tss->bitmap =3D IOBMP_INVALID_OFFSET; + + _set_tssldt_desc(gdt + TSS_ENTRY, 0, 0, SYS_DESC_tss_avail); + ltr(TSS_SELECTOR); +} + /* * Configure basic exception handling. This is prior to parsing the comma= nd * line or configuring a console, and needs to be as simple as possible. @@ -322,6 +396,8 @@ void __init traps_init(void) =20 if ( opt_fred ) { + const struct desc_ptr idtr =3D {}; + #ifdef CONFIG_PV32 if ( opt_pv32 ) { @@ -329,16 +405,27 @@ void __init traps_init(void) printk(XENLOG_INFO "Disabling PV32 due to FRED\n"); } #endif + + init_fred(); + set_in_cr4(X86_CR4_FRED); + + /* + * Invalidate the IDT as it's not used. Set up a minimal TSS. The + * LDT was configured by bsp_early_traps_init(). + */ + lidt(&idtr); + init_fred_tss(); + setup_force_cpu_cap(X86_FEATURE_XEN_FRED); printk("Using FRED event delivery\n"); } else { + load_system_tables(); + printk("Using IDT event delivery\n"); } =20 - load_system_tables(); - init_ler(); =20 percpu_traps_init(); @@ -353,7 +440,11 @@ void __init traps_init(void) */ void __init bsp_traps_reinit(void) { - load_system_tables(); + if ( opt_fred ) + init_fred(); + else + load_system_tables(); + percpu_traps_init(); } =20 @@ -368,7 +459,7 @@ void percpu_traps_init(void) * allocated, limiting the placement of the traps_init() call, and gets * re-done anyway by bsp_traps_reinit(). */ - if ( system_state > SYS_STATE_early_boot ) + if ( !opt_fred && system_state > SYS_STATE_early_boot ) legacy_syscall_init(); =20 if ( cpu_has_xen_lbr ) @@ -384,7 +475,29 @@ void percpu_traps_init(void) */ void asmlinkage percpu_early_traps_init(void) { - load_system_tables(); + if ( opt_fred ) + { + seg_desc_t *gdt =3D this_cpu(gdt) - FIRST_RESERVED_GDT_ENTRY; + const struct desc_ptr gdtr =3D { + .base =3D (unsigned long)gdt, + .limit =3D LAST_RESERVED_GDT_BYTE, + }, idtr =3D {}; + + lgdt(&gdtr); + + init_fred(); + write_cr4(read_cr4() | X86_CR4_FRED); + + /* + * Invalidate the IDT (not used) and LDT (not set up yet). Set up= a + * minimal TSS. + */ + lidt(&idtr); + init_fred_tss(); + lldt(0); + } + else + load_system_tables(); } =20 static void __init __maybe_unused build_assertions(void) @@ -403,4 +516,11 @@ static void __init __maybe_unused build_assertions(voi= d) endof_field(struct cpu_info, guest_cpu_user_regs)) & 15); BUILD_BUG_ON((sizeof(struct cpu_info) - endof_field(struct cpu_info, _fred)) & 63); + + /* + * The x86 architecture is happy with TR.limit being less than 0x67, b= ut + * VT-x is not. VMExit unconditionally sets the limit to 0x67, meaning + * that HOST_TR_BASE needs to refer to a good TSS of at least this siz= e. + */ + BUILD_BUG_ON(sizeof(struct tss64) <=3D 0x67); } --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234242; cv=none; d=zohomail.com; s=zohoarc; b=lygyoptjLl646IfOws3YjIGTWkqENAeMLivAnqKpNMo/rFXaAYZJW6BW6OGQ5mUYdY9csuNre2UbkbhRyNK18O2zGBmN+ghTqQOx21KlmINfEwGLtv4ZwtxK7YRu1FxhD5AUudmL1lGp8MEHPDcnIeVbmRn9pRW/S+SNVSZKNXg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234242; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=cuNoDLVINXiEv4BH5R0XrplZaA/DMViGBRkmV2Hoar0=; b=VkdXOc75toYCaGnw1Bdr4809V+xJjbxDVZDX6rS/FMDEmaK4puxFceyXJ2q7pgmzUNB5e6Pi3l/605v2ahRWvXGm/n+dnRrNMTHYGkg8AcHumgj7UdZeCHOP2Qr8Ym7CWh+r4U1LYmLaEIx53uFXXtrvxT3RptKYmP4eUBHLlV0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234242861398.5474353116367; Fri, 27 Feb 2026 15:17:22 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243149.1543213 (Exim 4.92) (envelope-from ) id 1vw74r-0002eB-0y; Fri, 27 Feb 2026 23:16:57 +0000 Received: by outflank-mailman (output) from mailman id 1243149.1543213; Fri, 27 Feb 2026 23:16:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74q-0002cA-9b; Fri, 27 Feb 2026 23:16:56 +0000 Received: by outflank-mailman (input) for mailman id 1243149; Fri, 27 Feb 2026 23:16:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74o-0001Do-0q for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:54 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6538baf4-1432-11f1-9ccf-f158ae23cfc8; Sat, 28 Feb 2026 00:16:50 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-4806bf39419so26514525e9.1 for ; Fri, 27 Feb 2026 15:16:50 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:49 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6538baf4-1432-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234210; x=1772839010; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=cuNoDLVINXiEv4BH5R0XrplZaA/DMViGBRkmV2Hoar0=; b=nhaxy+kRcF+C2+tZvjT2wr31Q5Iuvdv8PS4XJUT5OGRin0oFuxhadey1qXJzpv+C4C xMfxBD+v8B92zhDBYgigeXRcsJ3dAT4jRmwHAIvDkFoi7yCn1p0vu05hFka6kIqxCR7j ETs+hecEm/6ooGJhAz2UWbME53LWxTuDlphsc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234210; x=1772839010; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=cuNoDLVINXiEv4BH5R0XrplZaA/DMViGBRkmV2Hoar0=; b=uVI3IgOaPa9Hc1ismpVdG8u4U7qgnM2dU58onOWt8x9stuXSMcvYlNDg7cspntGKp0 tzQCZ2kFLFWt1gZtpJwXcDsGeQhYld3JF0N7nlshdBEdzRHUrSQ1eViC0ff5OKtPHEJX sKPucq6/t78ssO8kjkjJR0I6cUp7E0jV+9/T/AplMjZoInOmzCUJzRIbnLtXC+4cFPrm A4Czc/w0Oheq4sH6S9Bwr+1U2bRR1y/dxtWPEcgwZSFdt8kwka1XTx1gDo5XuTuQdTq/ WxoOd0Ew4CUzftG8TzPLYM0WzUmdk7NDTpNmwZhlgVNFs1NVRkDXXD/1gLeNPtXuLYXE OeWw== X-Gm-Message-State: AOJu0YzXZt5MQmqfn7l79LRwW+KxKRba9qyiYC+bTs8mcPSU24LlY10I yx/B0+Xv3UvbjutnH+Mp8jXzU031IZmPO5X+O/EhJvC+Hr/BpEodmZhmjViquyQYYdTLo4UPqL/ E1qCtdT2RYKhF X-Gm-Gg: ATEYQzxegyOx4HMVIQ1D540v8VOsOuSd6OEfXsIj11bBGFVGNVZHjf/5Z2bw/Db5eYA aEeDl8SR+o1uVD9mCbFRkwNjAKi4fhSqiN5M6n4ZF/tOPA+ZbHa3QOkJu2EeDfWF9tFajn/pRvQ M04NwNmK+rE2JlHzqeM+ox3lQRUJQRG24MnubQscaM2fPHmVsXTkL9KQbm2FV8pmpE4joBFZOul lry9ZcJtxhJwk6KWyu30aviksM/UKMRrTz0LmiQRu2bYc5vdFN5pHA5s7O009ncspt0XVMqlegr JbwDQcVgGUeAccWI/blq7v7Hk42RZmf4DV9ksFKrkyB0c8nM9O7Iq9osaovfXLv4/cJENT17rjO g+2UyyL5O5kaU4JVfxhhulD7wLunHYRK/5QQOoML0fkcwsRR5kL3ktQNCfrkkdMexlPtbSAVWyS huxl7Wq1HSmqilgOxNeIx7fwDsfZQzssRrP+7Yf/w4lhq+SrEWdIyaNPvdKqf8z1pISG/hmx97O qqlkuMnkA== X-Received: by 2002:a05:600c:c16e:b0:475:ddad:c3a9 with SMTP id 5b1f17b1804b1-483c99348c5mr75009455e9.13.1772234209589; Fri, 27 Feb 2026 15:16:49 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 09/14] x86/pv: Adjust GS handling for FRED mode Date: Fri, 27 Feb 2026 23:16:31 +0000 Message-Id: <20260227231636.3955109-10-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234244430158500 When FRED is active, hardware automatically swaps GS when changing privileg= e, and the SWAPGS instruction is disallowed. For native OSes using GS as the thread local pointer this is a massive improvement on the pre-FRED architecture, but under Xen it makes handling PV guests more complicated. Specifically, it means that GS_BASE and GS_SHADOW are the opposite way around in FRED mode, as opposed to IDT mode. This leads to the following changes: * In load_segments(), we have to load both GSes. Account for this in the SWAP() condition and avoid the path with SWAGS. * In save_segments(), we need to read GS_SHADOW rather than GS_BASE. * In toggle_guest_mode(), we need to emulate SWAPGS. * In {read,write}_msr() which access the live registers, GS_SHADOW and GS_BASE need swapping. * In do_set_segment_base(), merge the SEGBASE_GS_{USER,KERNEL} cases and take FRED into account when choosing which base to update. SEGBASE_GS_USER_SEL was already an LKGS invocation (decades before FRED) so under FRED needs to be just a MOV %gs. Simply skip the SWAPGSes. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * Adjust GS accesses for emulated {RD,WR}MSR too. --- xen/arch/x86/domain.c | 16 +++++++++++----- xen/arch/x86/pv/domain.c | 22 ++++++++++++++++++++-- xen/arch/x86/pv/emul-priv-op.c | 24 +++++++++++++++--------- xen/arch/x86/pv/misc-hypercalls.c | 16 ++++++++++------ 4 files changed, 56 insertions(+), 22 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index e658c2d647b7..9c1f6ef76d52 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1791,9 +1791,10 @@ static void load_segments(struct vcpu *n) =20 /* * Figure out which way around gsb/gss want to be. gsb needs to be - * the active context, and gss needs to be the inactive context. + * the active context, and gss needs to be the inactive context, + * unless we're in FRED mode where they're reversed. */ - if ( !(n->arch.flags & TF_kernel_mode) ) + if ( !(n->arch.flags & TF_kernel_mode) ^ opt_fred ) SWAP(gsb, gss); =20 if ( using_svm() && (n->arch.pv.fs | n->arch.pv.gs) <=3D 3 ) @@ -1814,7 +1815,9 @@ static void load_segments(struct vcpu *n) =20 if ( !fs_gs_done && !compat ) { - if ( read_cr4() & X86_CR4_FSGSBASE ) + unsigned long cr4 =3D read_cr4(); + + if ( !(cr4 & X86_CR4_FRED) && (cr4 & X86_CR4_FSGSBASE) ) { __wrgsbase(gss); __wrfsbase(n->arch.pv.fs_base); @@ -1931,6 +1934,9 @@ static void load_segments(struct vcpu *n) * Guests however cannot use SWAPGS, so there is no mechanism to modify the * inactive GS base behind Xen's back. Therefore, Xen's copy of the inact= ive * GS base is still accurate, and doesn't need reading back from hardware. + * + * Under FRED, hardware automatically swaps GS for us, so SHADOW_GS is the + * active GS from the guest's point of view. */ static void save_segments(struct vcpu *v) { @@ -1946,12 +1952,12 @@ static void save_segments(struct vcpu *v) if ( read_cr4() & X86_CR4_FSGSBASE ) { fs_base =3D __rdfsbase(); - gs_base =3D __rdgsbase(); + gs_base =3D opt_fred ? rdmsr(MSR_SHADOW_GS_BASE) : __rdgsbase(= ); } else { fs_base =3D rdmsr(MSR_FS_BASE); - gs_base =3D rdmsr(MSR_GS_BASE); + gs_base =3D opt_fred ? rdmsr(MSR_SHADOW_GS_BASE) : rdmsr(MSR_G= S_BASE); } =20 v->arch.pv.fs_base =3D fs_base; diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index d16583a7454d..b85abb5ed903 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -14,9 +14,10 @@ #include #include #include -#include #include #include +#include +#include =20 #ifdef CONFIG_PV32 int8_t __read_mostly opt_pv32 =3D -1; @@ -514,11 +515,28 @@ void toggle_guest_mode(struct vcpu *v) * subsequent context switch won't bother re-reading it. */ gs_base =3D read_gs_base(); + + /* + * In FRED mode, not only are the two GSes the other way around (i.e. = we + * want to read GS_SHADOW here), the SWAPGS instruction is disallowed = so + * we have to emulate it. + */ + if ( opt_fred ) + { + unsigned long gs_shadow =3D rdmsr(MSR_SHADOW_GS_BASE); + + wrmsrns(MSR_SHADOW_GS_BASE, gs_base); + write_gs_base(gs_shadow); + + gs_base =3D gs_shadow; + } + else + asm volatile ( "swapgs" ); + if ( v->arch.flags & TF_kernel_mode ) v->arch.pv.gs_base_kernel =3D gs_base; else v->arch.pv.gs_base_user =3D gs_base; - asm volatile ( "swapgs" ); =20 _toggle_guest_pt(v); =20 diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index 87d3bbcf901f..81153084129a 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -25,6 +25,7 @@ #include #include #include +#include =20 #include =20 @@ -926,7 +927,7 @@ static int cf_check read_msr( case MSR_GS_BASE: if ( !cp->extd.lm ) break; - *val =3D read_gs_base(); + *val =3D opt_fred ? rdmsr(MSR_SHADOW_GS_BASE) : read_gs_base(); return X86EMUL_OKAY; =20 case MSR_SHADOW_GS_BASE: @@ -1066,17 +1067,22 @@ static int cf_check write_msr( if ( !cp->extd.lm || !is_canonical_address(val) ) break; =20 - if ( reg =3D=3D MSR_FS_BASE ) - write_fs_base(val); - else if ( reg =3D=3D MSR_GS_BASE ) - write_gs_base(val); - else if ( reg =3D=3D MSR_SHADOW_GS_BASE ) + switch ( reg ) { - write_gs_shadow(val); + case MSR_FS_BASE: + write_fs_base(val); + break; + + case MSR_SHADOW_GS_BASE: curr->arch.pv.gs_base_user =3D val; + fallthrough; + case MSR_GS_BASE: + if ( (reg =3D=3D MSR_GS_BASE) ^ opt_fred ) + write_gs_base(val); + else + write_gs_shadow(val); + break; } - else - ASSERT_UNREACHABLE(); return X86EMUL_OKAY; =20 case MSR_EFER: diff --git a/xen/arch/x86/pv/misc-hypercalls.c b/xen/arch/x86/pv/misc-hyper= calls.c index 4c2abeb4add8..2c9cf50638db 100644 --- a/xen/arch/x86/pv/misc-hypercalls.c +++ b/xen/arch/x86/pv/misc-hypercalls.c @@ -11,6 +11,7 @@ =20 #include #include +#include =20 long do_set_debugreg(int reg, unsigned long value) { @@ -192,11 +193,12 @@ long do_set_segment_base(unsigned int which, unsigned= long base) =20 case SEGBASE_GS_USER: v->arch.pv.gs_base_user =3D base; - write_gs_shadow(base); - break; - + fallthrough; case SEGBASE_GS_KERNEL: - write_gs_base(base); + if ( (which =3D=3D SEGBASE_GS_KERNEL) ^ opt_fred ) + write_gs_base(base); + else + write_gs_shadow(base); break; } break; @@ -209,7 +211,8 @@ long do_set_segment_base(unsigned int which, unsigned l= ong base) * We wish to update the user %gs from the GDT/LDT. Currently, the * guest kernel's GS_BASE is in context. */ - asm volatile ( "swapgs" ); + if ( !opt_fred ) + asm volatile ( "swapgs" ); =20 if ( sel > 3 ) /* Fix up RPL for non-NUL selectors. */ @@ -247,7 +250,8 @@ long do_set_segment_base(unsigned int which, unsigned l= ong base) /* Update the cache of the inactive base, as read from the GDT/LDT= . */ v->arch.pv.gs_base_user =3D read_gs_base(); =20 - asm volatile ( safe_swapgs ); + if ( !opt_fred ) + asm volatile ( safe_swapgs ); break; } =20 --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234237; cv=none; d=zohomail.com; s=zohoarc; b=YzcOBa2lCbGYriTQ+7fYvfg5azumSg82H/mLTadXXUZS0J+4tU4+Qfn3FhpcbOaexsTWaLAZpnz/id3MsSa7U5cZ++/dDDIagzWT3O8is+msTmhh1yYTpzWE85sEQTB4BYiofozbx7JEVOrWGVGBKP8j80lmhIY51KIhQEb7++8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234237; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=IPkD49jGeQX0+NTjYasufq4vkWv8Wa7wJQ5GOxuUBzw=; b=DQTG7XflFiUkHQMPA2fk2wsPwdva8r+56hPNQSJOy/ePp8o0Z4wnmsZ5J5dfC4Q3ATjvD2Lse0l796GBly+CttllSiR1cJTWtZkPALemudSRJcf2mILFJR3sCXRMNKkWRBM0SIh3afKnPJqnSjVWYscyoiXOkLU1XE15QGFbkkI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234237419894.8217631285047; Fri, 27 Feb 2026 15:17:17 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243151.1543219 (Exim 4.92) (envelope-from ) id 1vw74r-0002rE-Sr; Fri, 27 Feb 2026 23:16:57 +0000 Received: by outflank-mailman (output) from mailman id 1243151.1543219; Fri, 27 Feb 2026 23:16:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74r-0002ok-A5; Fri, 27 Feb 2026 23:16:57 +0000 Received: by outflank-mailman (input) for mailman id 1243151; Fri, 27 Feb 2026 23:16:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74p-0001Do-0s for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:55 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 65a17652-1432-11f1-9ccf-f158ae23cfc8; Sat, 28 Feb 2026 00:16:51 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-4398d9a12c6so2002729f8f.2 for ; Fri, 27 Feb 2026 15:16:51 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:49 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 65a17652-1432-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234210; x=1772839010; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=IPkD49jGeQX0+NTjYasufq4vkWv8Wa7wJQ5GOxuUBzw=; b=aWu0v+aKBSi+ZKXTbUAIbhqLiQ3t0UCag3SY/IXNU8JtgkdzoJIrQ60VGwJb9cv4Y4 jNGvfp2rCW7wSHNUZy3zh3kDtFHniQVLflFDdMPuqlR4IRkD2OQJX3rR/25hji2Yr8HH VuPEQ7C6rHI5+6XRZF9iwNbB4CWl99pMP+7y8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234210; x=1772839010; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=IPkD49jGeQX0+NTjYasufq4vkWv8Wa7wJQ5GOxuUBzw=; b=DdWnCDvVvP4AqNzRXCvmgu0RjdtbedXT+uxnK61aVSi9EDuCwNfkBsgDWQ4Vcwko49 xwMSpOstGei/PHJf3MFw9W2upjdGZ+sNsAQk4rh7CnqLKupX75CqsoAhnEOHxOpGkgOX ddq/UDaizVe57NPvgGQxav1UFkWJ0pd8Ys2PB0ddmk/x8uDTuz37FymzbxcyPMreON6A ekJ9BcEk14xtQ6f17AYzFMHurBy/GchNZf9lKE7PgF/v1ObU126ndDvhd3KeqNMAqTWD JqOzLffncvpIa/J4wsVLsLVVQqARTK4gs1tSxN10sECeeCgOCR60X7XjvUHz2uuzHfZz 63vA== X-Gm-Message-State: AOJu0Yynw/kQWYsK7Gl9vJD84x3w0caPwULE5E+XnTFTR8JB4EaySAv4 oeIifRzWvhN0xnR5cXv0IGhvQ83fwdGX8zMaSmX5PJ09dyR/k6cavq26iOzcfMyeRYpNn8FjcDu rBGxP2XccOA== X-Gm-Gg: ATEYQzwLpygoeAfajVlmhzf9oEj32veKnLugd0DsSSkyl+XViBax4otbgprtdLRlHlv e1il92qsxUkEZ0jvQkPNWGWwkp7uXKp/WfvLRgjw68mj60YUlX8DXRourpImchy6ITOvimnvd79 +X9F5L7LKCL2QulJqnKjX+7PoZzC30h0Y4gbGJ3OP+f9EHl0I3PS+aeYp8j1CpYyycst19XIttL EumeAkxACZMWjf3iF8akKhdggWsYxv261LEgmXnq3EOrtb5y3wzilNEhT/BAQPjPn4VXlADKy5X GaC6zhylzoN2GHUUZ13EIYDYARmyO6C+cFiU0EQEo296G16TQa7xeLtuQrNMk0i4ui0GR/qOdc4 iWhfv2RJkYNt7XQ10YJvl8KfliWzwPzFnaQjXMVakXSmfr3vv+U1r+BCIs74URBXCUy4YjqISdn 3yAkuBG23jG3jY4ViUIaqAwz0aDJdwiQi+cZ7NYVQ1gRbL3LadQRIR58ae6qXPIHi62ocJ1fo= X-Received: by 2002:a05:6000:4301:b0:439:8487:73b2 with SMTP id ffacd0b85a97d-4399ddf1330mr8136464f8f.14.1772234210254; Fri, 27 Feb 2026 15:16:50 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 10/14] x86/pv: Guest exception handling in FRED mode Date: Fri, 27 Feb 2026 23:16:32 +0000 Message-Id: <20260227231636.3955109-11-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234238358158500 Under FRED, entry_from_pv() handles everything. To start with, implement exception handling in the same manner as entry_from_xen(), although we can unconditionally enable interrupts after the async/fatal events. After entry_from_pv() returns, test_all_events() needs to run to perform exception and interrupt injection. Split entry_FRED_R3() into two and introduce eretu_exit_to_guest() as the latter half, coming unilaterally from restore_all_guest(). For all of this, there is a slightly complicated relationship with CONFIG_P= V. entry_FRED_R3() must exist irrespective of CONFIG_PV, because it's the entrypoint registered with hardware. For simplicity, entry_from_pv() is always called, but it collapses into fatal_trap() in the !PV case. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * Treat nested events as fatal. v3: * Adjust comments. * Group CP with others. It's definitely wrong for perf, but that's out the window anyway now that we're letting a compiler make the decision tree. v2: * New --- xen/arch/x86/traps.c | 78 +++++++++++++++++++++++++++++++- xen/arch/x86/x86_64/entry-fred.S | 13 +++++- xen/arch/x86/x86_64/entry.S | 4 +- 3 files changed, 92 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 48667c71d591..7563576fb477 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2266,9 +2266,85 @@ void asmlinkage check_ist_exit(const struct cpu_user= _regs *regs, bool ist_exit) =20 void asmlinkage entry_from_pv(struct cpu_user_regs *regs) { + struct fred_info *fi =3D cpu_regs_fred_info(regs); + uint8_t type =3D regs->fred_ss.type; + uint8_t vec =3D regs->fred_ss.vector; + /* Copy fred_ss.vector into entry_vector as IDT delivery would have do= ne. */ - regs->entry_vector =3D regs->fred_ss.vector; + regs->entry_vector =3D vec; + + if ( !IS_ENABLED(CONFIG_PV) ) + goto fatal; + + /* + * First, handle the asynchronous or fatal events. These are either + * unrelated to the interrupted context, or may not have valid context + * recorded, and all have special rules on how/whether to re-enable IR= Qs. + */ + if ( regs->fred_ss.nested ) + goto fatal; + + switch ( type ) + { + case X86_ET_EXT_INTR: + return do_IRQ(regs); + + case X86_ET_NMI: + return do_nmi(regs); + + case X86_ET_HW_EXC: + switch ( vec ) + { + case X86_EXC_DF: return do_double_fault(regs); + case X86_EXC_MC: return do_machine_check(regs); + } + break; + } =20 + /* + * With the asynchronous events handled, what remains are the synchron= ous + * ones. PV guest context always had interrupts enabled. + */ + local_irq_enable(); + + switch ( type ) + { + case X86_ET_HW_EXC: + case X86_ET_PRIV_SW_EXC: + case X86_ET_SW_EXC: + switch ( vec ) + { + case X86_EXC_PF: handle_PF(regs, fi->edata); break; + case X86_EXC_GP: do_general_protection(regs); break; + case X86_EXC_UD: do_invalid_op(regs); break; + case X86_EXC_NM: do_device_not_available(regs); break; + case X86_EXC_BP: do_int3(regs); break; + case X86_EXC_DB: handle_DB(regs, fi->edata); break; + case X86_EXC_CP: do_entry_CP(regs); break; + + case X86_EXC_DE: + case X86_EXC_OF: + case X86_EXC_BR: + case X86_EXC_NP: + case X86_EXC_SS: + case X86_EXC_MF: + case X86_EXC_AC: + case X86_EXC_XM: + do_trap(regs); + break; + + default: + goto fatal; + } + break; + + default: + goto fatal; + } + + return; + + fatal: fatal_trap(regs, false); } =20 diff --git a/xen/arch/x86/x86_64/entry-fred.S b/xen/arch/x86/x86_64/entry-f= red.S index 3c3320df22cb..a1ff9a4a9747 100644 --- a/xen/arch/x86/x86_64/entry-fred.S +++ b/xen/arch/x86/x86_64/entry-fred.S @@ -15,9 +15,20 @@ FUNC(entry_FRED_R3, 4096) mov %rsp, %rdi call entry_from_pv =20 +#ifdef CONFIG_PV + GET_STACK_END(14) + movq STACK_CPUINFO_FIELD(current_vcpu)(%r14), %rbx + + jmp test_all_events +#else + BUG /* Not Reached */ +#endif +END(entry_FRED_R3) + +FUNC(eretu_exit_to_guest) POP_GPRS eretu -END(entry_FRED_R3) +END(eretu_exit_to_guest) =20 /* The Ring0 entrypoint is at Ring3 + 0x100. */ .org entry_FRED_R3 + 0x100, 0xcc diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S index 8b83082413a5..17ca6a493906 100644 --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -63,7 +63,7 @@ UNLIKELY_END(syscall_no_callback) /* Conditionally clear DF */ and %esi, UREGS_eflags(%rsp) /* %rbx: struct vcpu */ -test_all_events: +LABEL(test_all_events, 0) ASSERT_NOT_IN_ATOMIC cli # tests must not race interrupts /*test_softirqs:*/ @@ -152,6 +152,8 @@ END(switch_to_kernel) FUNC_LOCAL(restore_all_guest) ASSERT_INTERRUPTS_DISABLED =20 + ALTERNATIVE "", "jmp eretu_exit_to_guest", X86_FEATURE_XEN_FRED + /* Stash guest SPEC_CTRL value while we can read struct vcpu. */ mov VCPU_arch_msrs(%rbx), %rdx mov VCPUMSR_spec_ctrl_raw(%rdx), %r15d --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234244; cv=none; d=zohomail.com; s=zohoarc; b=LGABTB7atD+dCZAU4QCOpjxFpvT1K8mLB75Trju/silJNo3fvyUN96N6wDm4I7Dq7j/K3zjA+GMWc8cDSck0s2SIfWJUkNhXNlTnuZWEOIQSOrZWQ5M1WUIjWiR+ZpLvEcn27x1hof5j6gns/I78RWH851Pp1RoY3cXnppczkuA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234244; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=+mPsNS3LpQ9n9lXMqkSeJXydtadjNiDxPpSog7A2Jaw=; b=nz3oyNrh+q24eWdOBvJmqwsnYMlIQvh0EnxDmmTbzZNw+WNWt+bPKsdV7FJwAXIrevz05XMno0JhkvbXfARHRSJORXrMM8pm9yYWqKlYUftIDjz+ZcCK8ELAzFdhQ3xky5/feLYINMzyvbSRmP045RrZglwBpmwdeagJI0yEwDQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234244186123.9924822489038; Fri, 27 Feb 2026 15:17:24 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243152.1543228 (Exim 4.92) (envelope-from ) id 1vw74t-00035m-1p; Fri, 27 Feb 2026 23:16:59 +0000 Received: by outflank-mailman (output) from mailman id 1243152.1543228; Fri, 27 Feb 2026 23:16:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74s-00032V-Bp; Fri, 27 Feb 2026 23:16:58 +0000 Received: by outflank-mailman (input) for mailman id 1243152; Fri, 27 Feb 2026 23:16:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74q-0001Do-1B for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:56 +0000 Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [2a00:1450:4864:20::442]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 66064ac5-1432-11f1-9ccf-f158ae23cfc8; Sat, 28 Feb 2026 00:16:51 +0100 (CET) Received: by mail-wr1-x442.google.com with SMTP id ffacd0b85a97d-4398f9e3b40so2692986f8f.1 for ; Fri, 27 Feb 2026 15:16:51 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:50 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 66064ac5-1432-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234211; x=1772839011; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+mPsNS3LpQ9n9lXMqkSeJXydtadjNiDxPpSog7A2Jaw=; b=PdjhBNUzXeKG5TFAcbNR1UbXPQwTxr46q7dh0n8XrILY8ncoEHcMbnPBtV741sLYe9 ZKmSRnSaJJ8aiFeIbSu3KUZ1iYE77MuDnUe0dGd39rgPt/A1rvMR2ZKCGHyxoANjDs6s caPxN4Mjd3Dl/fYLkltU2he5mEWdeiuDqONVk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234211; x=1772839011; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+mPsNS3LpQ9n9lXMqkSeJXydtadjNiDxPpSog7A2Jaw=; b=C4PDdfQAWDkpMVNe7Azk0b+WMjaiCRJhmgW1TL1dpb4EA70EFCJYxu46PRi+ZO7MZg 3jBtA6xVOnHb5XbTfpaTZzH/IQWtloOFjEExRyqM7Tk7PANC3M0pSJHIz5oKCnfRfU/G Um4PsD1mgKZbN1ZPaXyR1PlEyX4Q0wY0Q8u69/3gAQtZA/j5AP0IJf5xu4JZ8l1+Gh9A 44B7Df7ocwiClV+xl3fpnUUL/VHBhPp1pWVO5dKgPAPVtQg8bRIEcxoBl0lPIAcvCbrY 6CFhH6tM9NQKe+CvB+DJPBR8StLq6pvHsnFMHou1hYMkpsYA4XRUL+F0FMPvybCfeTuS 6saw== X-Gm-Message-State: AOJu0YzewyUad9XglwYsYOC3n2s/dj2OVEzcrmaEXqJweM+gONO1hoxS 47QC3Nyoy7AQxM+X8uId3fBSEntTgkkweBdsDGbjP9jQhJTkcb0xn8MXMyDAyBHvjUnLaqknQzO 6bTx8uh2OK5jf X-Gm-Gg: ATEYQzyI0CRFEDiPMAKVs96VXZqbxgex+bPLPjlCTUgSplaBcBRisSA+Bp7sVVZSnos 8S4aFXcSvcXyL6Y3TjrRoq28VhfKSTgVGFN0oL+TbkhX7s0ZdODBgp1GcvLBdnRhnrLAGWjUBQN QOMtV4Qr94w9l+JfefHxKylj/qqZF2vfyIrcZ6S++5TAK49QbnMOOqk0HKywPZ0G+FLM+ohjzRq lLYBOCkUTkYY2KuYjeUnZU2rOeNTbtxFe5jalw0XnolH9UWmf3DzhNfUR5zWrWJU0hdIaIcsxi1 gCZG9RY5naUcppdtsoccdW3+6+nF4MPsUT0tPWxzkXAXBc6DfMpbga8yeqQoXGXwwSYIlDgjx/0 DUgHpebFKKLjjDWWaNMNITBT67Ix9XIhVNQYY+VxS4dW+yAPO8Do8RUOOytRmNx4hb6uzu4Uprc 7vudvUAUjvSyKstyc3CvM+TIARdKPqygRmKJxZQnhC4fR/OjeHgeQ9Yvs0qeYjp26afQ0xJvQ= X-Received: by 2002:a05:6000:144c:b0:430:f3ab:56af with SMTP id ffacd0b85a97d-4399de4a662mr8040445f8f.48.1772234210832; Fri, 27 Feb 2026 15:16:50 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 11/14] x86/pv: ERETU error handling Date: Fri, 27 Feb 2026 23:16:33 +0000 Message-Id: <20260227231636.3955109-12-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234244414158500 ERETU can fault for guest reasons, and like IRET needs special handling to forward the error into the guest. As this is largely written in C, take the opportunity to better classify the sources of error, and in particilar, not forward errors that are actually Xen's fault into the guest, opting for a domain crash instead. Because ERETU does not enable NMIs if it faults, a corner case exists if an NMI was taken while in guest context, and the ERETU back out faults. Recov= ery must involve an ERETS with the interrupted context's NMI flag. See the comments for full details. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * Tweak comments. v2: * New --- xen/arch/x86/traps.c | 115 +++++++++++++++++++++++++++++++ xen/arch/x86/x86_64/entry-fred.S | 13 ++++ 2 files changed, 128 insertions(+) diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 7563576fb477..2f40f628cbff 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2348,6 +2348,113 @@ void asmlinkage entry_from_pv(struct cpu_user_regs = *regs) fatal_trap(regs, false); } =20 +void nocall eretu_error_dom_crash(void); + +/* + * Classify an event at the ERETU instruction, and handle if possible. + * Returns @true if handled, @false if the event should continue down the + * normal handlers. + */ +static bool handle_eretu_event(struct cpu_user_regs *regs) +{ + unsigned long recover; + + /* + * WARNING: The GPRs in gregs overlaps with regs. Only gregs->error_c= ode + * and later are legitimate to access. + */ + struct cpu_user_regs *gregs =3D + _p(regs->rsp - offsetof(struct cpu_user_regs, error_code)); + + /* + * The asynchronous or fatal events (INTR, NMI, #MC, #DF) have been de= alt + * with, meaning we only have synchronous ones to consider. Anything + * which isn't a hardware exception (e.g. #BP) wants handling normally. + */ + if ( regs->fred_ss.type !=3D X86_ET_HW_EXC ) + return false; + + /* + * Guests are permitted to write non-present GDT/LDT entries. Therefo= re + * #NP[sel] (%cs) and #SS[sel] (%ss) must be handled as guest errors. = The + * only other source of #SS is for a bad %ss-relative memory access in + * Xen, and if the stack is that bad, we'll have escalated to #DF. + * + * #PF can happen from ERETU accessing the GDT/LDT. Xen may translate + * these into #GP for the guest, so must be handled as guest errors. = In + * theory we can get #PF for a bad instruction fetch or bad stack acce= ss, + * but either of these will be fatal and not end up here. + */ + switch ( regs->fred_ss.vector ) + { + case X86_EXC_GP: + /* + * #GP[0] can occur because of a NULL %cs or %ss (which are a guest + * error), but some #GP[0]'s are errors in Xen (ERETU at SL !=3D 0= ), or + * errors of Xen's handling of guest state (bad metadata). + * + * These magic numbers came from the FRED Spec; they check that ER= ETU + * is trying to return to Ring 3, and that reserved or inapplicable + * bits are 0. + */ + if ( regs->error_code =3D=3D 0 && (gregs->cs & ~3) && (gregs->ss &= ~3) && + (regs->fred_cs.sl !=3D 0 || + (gregs->csx & 0xffffffffffff0003UL) !=3D 3 || + (gregs->rflags & 0xffffffffffc2b02aUL) !=3D 2 || + (gregs->ssx & 0xfff80003UL) !=3D 3) ) + { + recover =3D (unsigned long)eretu_error_dom_crash; + + if ( regs->fred_cs.sl ) + gprintk(XENLOG_ERR, "ERETU at SL %u\n", regs->fred_cs.sl); + else + gprintk(XENLOG_ERR, "Bad return state: csx %#lx, rflags %#= lx, ssx %#x\n", + gregs->csx, gregs->rflags, (unsigned int)gregs->ss= x); + break; + } + fallthrough; + case X86_EXC_NP: + case X86_EXC_SS: + case X86_EXC_PF: + recover =3D (unsigned long)entry_FRED_R3; + break; + + /* + * Handle everything else normally. e.g. #DB would be debugging + * activities in Xen. In theory we can get #UD if CR4.FRED gets + * cleared, but in practice if that were the case we wouldn't be h= ere + * handling the result. + */ + default: + return false; + } + + this_cpu(last_extable_addr) =3D regs->rip; + + /* + * If an NMI was taken in guest context and the ERETU faulted, NMIs wi= ll + * still be blocked. Therefore we copy the interrupted frame's NMI st= atus + * into our own, and must ERETS as part of recovery. + */ + regs->fred_ss.nmi =3D gregs->fred_ss.nmi; + + /* + * Next, copy the exception information from the current frame back on= to + * the interrupted frame, preserving the interrupted frame's %cs and %= ss. + */ + *cpu_regs_fred_info(regs) =3D *cpu_regs_fred_info(gregs); + gregs->ssx =3D (regs->ssx & ~0xffff) | gregs->ss; + gregs->csx =3D (regs->csx & ~0xffff) | gregs->cs; + gregs->error_code =3D regs->error_code; + gregs->entry_vector =3D regs->entry_vector; + + fixup_exception_return(regs, recover, 0); + + return true; +} + +void nocall eretu(void); + void asmlinkage entry_from_xen(struct cpu_user_regs *regs) { struct fred_info *fi =3D cpu_regs_fred_info(regs); @@ -2389,6 +2496,14 @@ void asmlinkage entry_from_xen(struct cpu_user_regs = *regs) if ( regs->eflags & X86_EFLAGS_IF ) local_irq_enable(); =20 + /* + * An event taken at the ERETU instruction may be because of bad guest + * state. If so, it will need special handling. + */ + if ( unlikely(regs->rip =3D=3D (unsigned long)eretu) && + handle_eretu_event(regs) ) + return; + switch ( type ) { case X86_ET_HW_EXC: diff --git a/xen/arch/x86/x86_64/entry-fred.S b/xen/arch/x86/x86_64/entry-f= red.S index a1ff9a4a9747..2fa57beb930c 100644 --- a/xen/arch/x86/x86_64/entry-fred.S +++ b/xen/arch/x86/x86_64/entry-fred.S @@ -27,9 +27,22 @@ END(entry_FRED_R3) =20 FUNC(eretu_exit_to_guest) POP_GPRS + + /* + * Exceptions here are handled by redirecting either to + * entry_FRED_R3() (for an error to be passed to the guest), or to + * eretu_error_dom_crash() (for a Xen error handling guest state). + */ +LABEL(eretu, 0) eretu END(eretu_exit_to_guest) =20 +FUNC(eretu_error_dom_crash) + PUSH_AND_CLEAR_GPRS + sti + call asm_domain_crash_synchronous /* Does not return */ +END(eretu_error_dom_crash) + /* The Ring0 entrypoint is at Ring3 + 0x100. */ .org entry_FRED_R3 + 0x100, 0xcc =20 --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234242; cv=none; d=zohomail.com; s=zohoarc; b=Ttc6GxGgPmLsY92aenc+13iHt0UX88MNxmmWHGRhCcVVxdPUSpDjpNO2vv2nFpsOY6xD/SmH1F7ejhjqOa5YU51ZLKEmnTH+BWCR4yTbzjFsyYW72rwRXyquBXQC6YXubHerSfX/5r2qGp38K1nNk+znOaGJ0sWlM6fylZneKKg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234242; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=XGrbegNxX52Qprjc9LHURGzyjTJEjBVjNc2DvWM4rPE=; b=izZOA6SfwY9XsrLLkWnxtSdpXYm+4D+lfEmLy0GeLSFOPirE3a34cNnZFntaIQUimkXx1gwy+cR3cDkbXHHjspS5MU6B9ur58sUmzeNfduOti6hSm0z3rgLvLnwRC35b8VM1azzuIORjX0553Jf91q/xDi4kkNWLwtJo2Ufj0v8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234242030614.817881338424; Fri, 27 Feb 2026 15:17:22 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243153.1543235 (Exim 4.92) (envelope-from ) id 1vw74t-0003EC-UW; Fri, 27 Feb 2026 23:16:59 +0000 Received: by outflank-mailman (output) from mailman id 1243153.1543235; Fri, 27 Feb 2026 23:16:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74t-0003AJ-1i; Fri, 27 Feb 2026 23:16:59 +0000 Received: by outflank-mailman (input) for mailman id 1243153; Fri, 27 Feb 2026 23:16:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74r-0001Do-1S for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:57 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 666569d4-1432-11f1-9ccf-f158ae23cfc8; Sat, 28 Feb 2026 00:16:52 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-43991cc3155so2439113f8f.0 for ; Fri, 27 Feb 2026 15:16:52 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:51 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 666569d4-1432-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234212; x=1772839012; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=XGrbegNxX52Qprjc9LHURGzyjTJEjBVjNc2DvWM4rPE=; b=cfR24MA2ZraMNZhxpjRXI0EIbZ8NDwIT124BCWEKOOxIpVODXNVfm7sqWxnY215+SB c9eTPTVUImIkeuhweszpCcqS3M9Xw1mC7mzexbtADsS31Fjb+cXZJ4OeEG7rmNpT3SUX uBRZsySD3IPaexCOHGFdiX0OrEEdQEFmYh/ds= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234212; x=1772839012; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XGrbegNxX52Qprjc9LHURGzyjTJEjBVjNc2DvWM4rPE=; b=TyGAYADbd++/NH1gXaEmYlw7vAUL2z/WxPH/tNVxnPjnFnL9qyrBCe7ejbjbKOIUk2 ekpCy8pakF0Xoy3YSIOHfgSOekoDlNVzXyycbtDkf2q4ldzhXHiH+obqzbQQipZud4Kf ssOeqe4zxo7Pexosf0poovHUv4hQdkQa0LQ4YmXqr6qcw6sz6P4+X5XXrdkjhiYRY7J/ qumSZkgJSO68ru0/jayaoNisvk6PJYV7DR8fFQNpXhG9P5tfo1shKl5KpqSylr/zgDgx /sMtyJ98qe+MISByUcOAPRBKGIiONIeSh0CHA977jI0Z+5zRxbvRIpDV9hr75zzDxmgu yl0g== X-Gm-Message-State: AOJu0YxIIe/ytVrI9jSYpvy/iDPrQ6J/E+bFIgxu2Jdrvaxmv2ZPb61Y jmTp7v+dDPXpbhYYuZVOkXyKIde0HR3mFFdEEqy56lnjSc0CW5tz6DfzFmorq2LX6gBFDy8gxli Pe/azSH3Y0w== X-Gm-Gg: ATEYQzyPiaMOoCLw84T75GywpbfjHVYkFwjH6Irtf4gIH3NOzv27anX6qR5zPi62HbC HTdYDnRAIfDLZMGRTu3GgSeKLa+H46OLCAZsA1hHSNP1n0QfVo0h7BZdkVs6EpS7CkrYK2HIi+y 9jQSlKNpoyvUeQR84YEoiNxdu0AesfS0F1PI+/AzRofCkvw7alhi+puYwKRsvlToBO7BB/nK6Fi QcyGNSBrMLuP9+OnRAafsQdJFOZV8WLaVstiNHpQ8vSCmFnWjvQMBR732P/MOfDUEntimTUSl5N UBmzh88iINf2bJXOwpj8kakfar2j41Di5ti6Sok4XoMjsR+Nmnl2VPQrh5v570j4KWkvlXRj0ME awTQaJ1C944J8pDPoeGc6ehBhIukGsH5SSQ8gopQIuYzy2sNTnQAsUOCNo007nq0w7TqaKsAxhX EkyzI8rXMtRXFoxL4LM/ZOOmyB75rW6JGrzq9PpbOwsY4Ig9MfnJLxps3cx1qxRtDKRNV6XOM= X-Received: by 2002:a05:6000:2482:b0:439:852f:c9e0 with SMTP id ffacd0b85a97d-4399de21f73mr7666076f8f.47.1772234211529; Fri, 27 Feb 2026 15:16:51 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 12/14] x86/pv: System call handling in FRED mode Date: Fri, 27 Feb 2026 23:16:34 +0000 Message-Id: <20260227231636.3955109-13-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234242412158500 Under FRED, entry_from_pv() handles everything, even system call instructio= ns. This means more of our logic is written in C now, rather than assembly. In order to facilitate this, introduce pv_inject_callback(), which reuses struct trap_bounce infrastructure to inject the syscall/sysenter callbacks. This in turns requires some !PV compatibility for pv_inject_callback() and pv_hypercall() which can both be ASSERT_UNREACHABLE(). For each of INT $N, SYSCALL and SYSENTER, FRED gives us interrupted context which was previously lost. As the guest can't see FRED, Xen has to lose st= ate in the same way to maintain the prior behaviour. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v3: * Simplify DCE handling. * Add ASSERT_UNREACHABLE() to pv_inject_callback(). * Adjust comment for X86_ET_SW_INT v2: * New --- xen/arch/x86/include/asm/domain.h | 2 + xen/arch/x86/include/asm/hypercall.h | 2 - xen/arch/x86/pv/traps.c | 39 ++++++++ xen/arch/x86/traps.c | 131 +++++++++++++++++++++++++++ 4 files changed, 172 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/d= omain.h index 94b0cf7f1d95..ad7f6adb2cb9 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -725,6 +725,8 @@ void arch_vcpu_regs_init(struct vcpu *v); struct vcpu_hvm_context; int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context = *ctx); =20 +void pv_inject_callback(unsigned int type); + #ifdef CONFIG_PV void pv_inject_event(const struct x86_event *event); #else diff --git a/xen/arch/x86/include/asm/hypercall.h b/xen/arch/x86/include/as= m/hypercall.h index bf2f0e169aef..d042a61d1702 100644 --- a/xen/arch/x86/include/asm/hypercall.h +++ b/xen/arch/x86/include/asm/hypercall.h @@ -18,9 +18,7 @@ =20 #define __HYPERVISOR_paging_domctl_cont __HYPERVISOR_arch_1 =20 -#ifdef CONFIG_PV void pv_hypercall(struct cpu_user_regs *regs); -#endif =20 void pv_ring1_init_hypercall_page(void *p); void pv_ring3_init_hypercall_page(void *p); diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c index b0395b99145a..c863ab9d372a 100644 --- a/xen/arch/x86/pv/traps.c +++ b/xen/arch/x86/pv/traps.c @@ -20,6 +20,8 @@ #include #include =20 +#include + void pv_inject_event(const struct x86_event *event) { struct vcpu *curr =3D current; @@ -96,6 +98,43 @@ void pv_inject_event(const struct x86_event *event) } } =20 +void pv_inject_callback(unsigned int type) +{ + struct vcpu *curr =3D current; + struct trap_bounce *tb =3D &curr->arch.pv.trap_bounce; + unsigned long rip; + bool irq; + + ASSERT(is_pv_64bit_vcpu(curr)); + + switch ( type ) + { + case CALLBACKTYPE_syscall: + rip =3D curr->arch.pv.syscall_callback_eip; + irq =3D curr->arch.pv.vgc_flags & VGCF_syscall_disables_events; + break; + + case CALLBACKTYPE_syscall32: + rip =3D curr->arch.pv.syscall32_callback_eip; + irq =3D curr->arch.pv.syscall32_disables_events; + break; + + case CALLBACKTYPE_sysenter: + rip =3D curr->arch.pv.sysenter_callback_eip; + irq =3D curr->arch.pv.sysenter_disables_events; + break; + + default: + ASSERT_UNREACHABLE(); + rip =3D 0; + irq =3D false; + break; + } + + tb->flags =3D TBF_EXCEPTION | (irq ? TBF_INTERRUPT : 0); + tb->eip =3D rip; +} + /* * Called from asm to set up the MCE trapbounce info. * Returns false no callback is set up, else true. diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 2f40f628cbff..e2c35a046e6b 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -51,6 +52,8 @@ #include #include =20 +#include + /* * opt_nmi: one of 'ignore', 'dom0', or 'fatal'. * fatal: Xen prints diagnostic message and then hangs. @@ -2267,6 +2270,7 @@ void asmlinkage check_ist_exit(const struct cpu_user_= regs *regs, bool ist_exit) void asmlinkage entry_from_pv(struct cpu_user_regs *regs) { struct fred_info *fi =3D cpu_regs_fred_info(regs); + struct vcpu *curr =3D current; uint8_t type =3D regs->fred_ss.type; uint8_t vec =3D regs->fred_ss.vector; =20 @@ -2309,6 +2313,38 @@ void asmlinkage entry_from_pv(struct cpu_user_regs *= regs) =20 switch ( type ) { + case X86_ET_SW_INT: + /* + * For better or worse, Xen writes IDT vectors 3 and 4 with DPL3 (= so + * INT3/INTO work), making INT $3/4 indistinguishable, and the gue= st + * choice of DPL for these vectors is ignored. + * + * Have them fall through into X86_ET_HW_EXC, as #BP in particular + * needs handling by do_int3() in case an external debugger is + * attached. + * + * As the event type is provided, INT $N instructions don't need #= GP + * tricks to spot, and INT $0x80 doesn't need a fastpath. As the + * guest is necessary PV64, INT $0x82 has no special meaning eithe= r. + * + * When converting to a fault, hardware finally gives us enough + * information to account for prefixes, so provide the more correct + * behaviour rather than assuming the instruction was two bytes lo= ng. + */ + if ( vec !=3D X86_EXC_BP && vec !=3D X86_EXC_OF ) + { + const struct trap_info *ti =3D &curr->arch.pv.trap_ctxt[vec]; + + if ( permit_softint(TI_GET_DPL(ti), curr, regs) ) + pv_inject_sw_interrupt(vec); + else + { + regs->rip -=3D regs->fred_ss.insnlen; + pv_inject_hw_exception(X86_EXC_GP, (vec << 3) | X86_XEC_ID= T); + } + break; + } + fallthrough; case X86_ET_HW_EXC: case X86_ET_PRIV_SW_EXC: case X86_ET_SW_EXC: @@ -2338,6 +2374,101 @@ void asmlinkage entry_from_pv(struct cpu_user_regs = *regs) } break; =20 + case X86_ET_OTHER: + switch ( regs->fred_ss.vector ) + { + case 1: /* SYSCALL */ + { + /* + * FRED delivery preserves the interrupted %cs/%ss, but previo= usly + * SYSCALL lost the interrupted selectors, and SYSRET forced t= he + * use of the ones in MSR_STAR. + * + * The guest isn't aware of FRED, so recreate the legacy + * behaviour. + * + * The non-FRED SYSCALL path sets TRAP_syscall in entry_vector= to + * signal that SYSRET can be used, but this isn't relevant in = FRED + * mode. + * + * When setting the selectors, clear all upper metadata again = for + * backwards compatibility. In particular fred_ss.swint becom= es + * pend_DB on ERETx, and nothing else in the pv_hypercall() wo= uld + * clean up. + * + * When converting to a fault, hardware finally gives us enough + * information to account for prefixes, so provide the more + * correct behaviour rather than assuming the instruction was = two + * bytes long. + */ + bool l =3D regs->fred_ss.l; + unsigned int len =3D regs->fred_ss.insnlen; + + regs->ssx =3D l ? FLAT_KERNEL_SS : FLAT_USER_SS32; + regs->csx =3D l ? FLAT_KERNEL_CS64 : FLAT_USER_CS32; + + if ( guest_kernel_mode(curr, regs) ) + pv_hypercall(regs); + else if ( (l ? curr->arch.pv.syscall_callback_eip + : curr->arch.pv.syscall32_callback_eip) =3D=3D 0 ) + { + regs->rip -=3D len; + pv_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); + } + else + { + /* + * The PV ABI, given no virtual SYSCALL_MASK, hardcodes th= at + * DF is cleared. Other flags are handled in the same way= as + * interrupts and exceptions in create_bounce_frame(). + */ + regs->eflags &=3D ~X86_EFLAGS_DF; + pv_inject_callback(l ? CALLBACKTYPE_syscall + : CALLBACKTYPE_syscall32); + } + break; + } + + case 2: /* SYSENTER */ + { + /* + * FRED delivery preserves the interrupted state, but previous= ly + * SYSENTER discarded almost everything. + * + * The guest isn't aware of FRED, so recreate the legacy + * behaviour. + * + * When setting the selectors, clear all upper metadata. In + * particular fred_ss.swint becomes pend_DB on ERETx. + * + * When converting to a fault, hardware finally gives us enough + * information to account for prefixes, so provide the more + * correct behaviour rather than assuming the instruction was = two + * bytes long. + */ + unsigned int len =3D regs->fred_ss.insnlen; + + regs->ssx =3D FLAT_USER_SS; + regs->rsp =3D 0; + regs->eflags &=3D ~(X86_EFLAGS_VM | X86_EFLAGS_IF); + regs->csx =3D 3; + regs->rip =3D 0; + + if ( !curr->arch.pv.sysenter_callback_eip ) + { + regs->rip -=3D len; + pv_inject_hw_exception(X86_EXC_GP, 0); + } + else + pv_inject_callback(CALLBACKTYPE_sysenter); + break; + } + + default: + goto fatal; + } + break; + default: goto fatal; } --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234236; cv=none; d=zohomail.com; s=zohoarc; b=Wc5hF4P1SfCwl9SzIGocVPYdwZBUTvBXO2nnL7hYjMOWpwE3euJmdou+YRjwdvPbNBYRsa6NdWqk+EG9BuQuFDcJWDcA/wUsbM27bqKxZOwnnQRUbB+9KQnXPTcvLAtYchzXuae1wfSMLVmg9mUd1ai9l+6+ox3uRL8xanOjgg8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234236; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=x/38gQJt4Duoysgo51k9uCF7ZRs4cy2MMdxCGTZF0sM=; b=Cz1G5U6XmrmB1L8w3x8bS10CSF4zQxKg1+VxM9VgBeC9XebMkz4xIAmXktTVPgCH+Us3s1jNWPFCeyIq+eQeriM1Yf2jemrkkTvLhri7+VgRx1uCWIsYTMmXx8CG/s7Y4GS7g5NK8KeGHuvzThlf0eulQRXWh6Oma1roUc9OPMY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234236354948.1815900418022; Fri, 27 Feb 2026 15:17:16 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243150.1543205 (Exim 4.92) (envelope-from ) id 1vw74q-0002Ys-4b; Fri, 27 Feb 2026 23:16:56 +0000 Received: by outflank-mailman (output) from mailman id 1243150.1543205; Fri, 27 Feb 2026 23:16:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74p-0002WH-Px; Fri, 27 Feb 2026 23:16:55 +0000 Received: by outflank-mailman (input) for mailman id 1243150; Fri, 27 Feb 2026 23:16:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74o-0008WD-45 for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:54 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 670b5881-1432-11f1-b164-2bf370ae4941; Sat, 28 Feb 2026 00:16:53 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-4398e850783so1818829f8f.0 for ; Fri, 27 Feb 2026 15:16:53 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:51 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 670b5881-1432-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234213; x=1772839013; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=x/38gQJt4Duoysgo51k9uCF7ZRs4cy2MMdxCGTZF0sM=; b=GwO9z+1DaK9BHfSRVqY8Diu6eVJb4bJSYHwF8F5cOUbWPqQs1wN1++kMotfSrKBAl8 +eWXfnAeSgAFW5GXsipzHoFWtOdungSB+Y85070W6Q0NonZJEJfI32bUjSSsPx7ij2UP NOA1QMmhq1Za0WeUEBhFI96PJkcSD3LktowuQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234213; x=1772839013; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=x/38gQJt4Duoysgo51k9uCF7ZRs4cy2MMdxCGTZF0sM=; b=YxDvAZ7w5aKNTlES29maHt7pMKvVLeGnSMSQY6OifS2dj0TUEf298ncQdbgArykNrZ lU5FF/GSUTB2s7lGaBW4rdsqvLp+VJg8/Np4pzvoN+udem5dN8m4UpBa0KhBY8znVhzn HuiCxb4xKKcncKPEVMg89g4ewNrtnTyrm0wWhALnLeO3wMKHld0xUlG3sNNSXu2LAHAy Wuce0oROHYCZRr+i9feqo+Sj236B8S3eMV3GPe28N0Z8pE+oYq/MZUdYueupk6gggr6s hysC3Of69D7TmkEwGPxQS/qd2Bijw45LZc59r3XutGSnlA3bjadd+PEEBzNBHgPSCnYu M/2w== X-Gm-Message-State: AOJu0YyN05C3f0WS2jlsOyM/JZXfKYPl1A4v+7r4NmrK/4SvXWNpsEjJ NokQXvlrv9bCPoGLxflE11boSNWbsq9+Dn1OY0/HR44IkHXRXOdVrOW7c3OcfIyHGWVkB/k1tg8 qC4tM X-Gm-Gg: ATEYQzwxTcOMy3RAOZ141Knqh9zIAnYodc0jirAuUS9onALlU5hCYvYmbCFj7xVFZgl m0ATV0aDiU8qLhXXOWWsqXqFirhWmottTk9dPJBklSZ1gIuOuqiGSlfQciBNI4rNESHW3hTFk6Z YuCGx7b17o7i1d+97K9dey/Zm0wU/wAjh7jBaDj59wuaxMElxgVJyfborxDKM/5OUmeMEu8DgdL 7WmLU5cvTXA/vywBKFF/225gchmGtQDHCsStFRKAGxiYHngbQ6Vyke/GLU7B3L89AdibFij3lQ8 tatM4zxzlWuEDmKlgVSG73Xf6C6lvEfT8dGdeaQ9mt8flve3qmAgQO18fDX9q1g+8DOVGjFX8pB nK46ZLK1C/Q9dljwDMyv5GIoBBreZKixb9jqOujmqO2Wdp7mS1qbJ+w4K9vtTPhoW3hvuHXuXBp keoM0LyMZnZsfLa0Mi4HWun+sGpg7kmYsU8HYRgf3o9cfyQL8hxqtVbGO0MERlJ/gMaswR6xG4r yUHn2Kmvw== X-Received: by 2002:a5d:5703:0:b0:439:9203:595a with SMTP id ffacd0b85a97d-4399de2fd89mr5736542f8f.43.1772234212143; Fri, 27 Feb 2026 15:16:52 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 13/14] x86: Clamp reserved bits in eflags more aggressively Date: Fri, 27 Feb 2026 23:16:35 +0000 Message-Id: <20260227231636.3955109-14-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234238370158501 ERETU, unlike IRET, requires the sticky-1 bit (bit 2) be set, and reserved bits to be clear. Notably this means that dom0_construct() must set X86_EFLAGS_MBS in order for a PV dom0 to start. Xen has been overly lax with reserved bit handling. Adjust arch_set_info_guest*() and hypercall_iret() which consume flags to clamp the reserved bits for all guest types. This is a minor ABI change, but by the same argument as commit 9f892f84c279 ("x86/domctl: Stop using XLAT_cpu_user_regs()"); the reserved bits would get clamped like this naturally by hardware when the vCPU is run. This allows PV guests to start when Xen is using FRED mode. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 Still slightly RFC. Testing still in progress. v3: * Rewrite the commit message. v2: * New The handling of VM is complicated. It turns out that it's simply ignored by IRET in Long Mode (i.e. clearing it commit 0e47f92b0725 ("x86: force EFLAGS.IF on when exiting to PV guests") wasn't actually necessary) but ERETU does care. But, it's unclear how to handle this in in arch_set_info(). We must preser= ve it for HVM guests (which can use vm86 mode). PV32 has special handling but only in hypercall_iret(), not in arch_set_info(). --- xen/arch/x86/domain.c | 4 ++-- xen/arch/x86/hvm/domain.c | 4 ++-- xen/arch/x86/include/asm/x86-defns.h | 7 +++++++ xen/arch/x86/pv/dom0_build.c | 2 +- xen/arch/x86/pv/iret.c | 8 +++++--- 5 files changed, 17 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 9c1f6ef76d52..1372a65d8123 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1244,7 +1244,7 @@ int arch_set_info_guest( v->arch.user_regs.rax =3D c.nat->user_regs.rax; v->arch.user_regs.rip =3D c.nat->user_regs.rip; v->arch.user_regs.cs =3D c.nat->user_regs.cs; - v->arch.user_regs.rflags =3D c.nat->user_regs.rflags; + v->arch.user_regs.rflags =3D (c.nat->user_regs.rflags &= X86_EFLAGS_ALL) | X86_EFLAGS_MBS; v->arch.user_regs.rsp =3D c.nat->user_regs.rsp; v->arch.user_regs.ss =3D c.nat->user_regs.ss; v->arch.pv.es =3D c.nat->user_regs.es; @@ -1268,7 +1268,7 @@ int arch_set_info_guest( v->arch.user_regs.eax =3D c.cmp->user_regs.eax; v->arch.user_regs.eip =3D c.cmp->user_regs.eip; v->arch.user_regs.cs =3D c.cmp->user_regs.cs; - v->arch.user_regs.eflags =3D c.cmp->user_regs.eflags; + v->arch.user_regs.eflags =3D (c.cmp->user_regs.eflags &= X86_EFLAGS_ALL) | X86_EFLAGS_MBS; v->arch.user_regs.esp =3D c.cmp->user_regs.esp; v->arch.user_regs.ss =3D c.cmp->user_regs.ss; v->arch.pv.es =3D c.cmp->user_regs.es; diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c index 155d61db13f8..a0e811ea47a0 100644 --- a/xen/arch/x86/hvm/domain.c +++ b/xen/arch/x86/hvm/domain.c @@ -194,7 +194,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struc= t vcpu_hvm_context *ctx) uregs->rsi =3D regs->esi; uregs->rdi =3D regs->edi; uregs->rip =3D regs->eip; - uregs->rflags =3D regs->eflags; + uregs->rflags =3D (regs->eflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; =20 v->arch.hvm.guest_cr[0] =3D regs->cr0; v->arch.hvm.guest_cr[3] =3D regs->cr3; @@ -245,7 +245,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struc= t vcpu_hvm_context *ctx) uregs->rsi =3D regs->rsi; uregs->rdi =3D regs->rdi; uregs->rip =3D regs->rip; - uregs->rflags =3D regs->rflags; + uregs->rflags =3D (regs->rflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; =20 v->arch.hvm.guest_cr[0] =3D regs->cr0; v->arch.hvm.guest_cr[3] =3D regs->cr3; diff --git a/xen/arch/x86/include/asm/x86-defns.h b/xen/arch/x86/include/as= m/x86-defns.h index 0a0ba83de786..edeb0b4ff95a 100644 --- a/xen/arch/x86/include/asm/x86-defns.h +++ b/xen/arch/x86/include/asm/x86-defns.h @@ -27,6 +27,13 @@ (X86_EFLAGS_CF | X86_EFLAGS_PF | X86_EFLAGS_AF | \ X86_EFLAGS_ZF | X86_EFLAGS_SF | X86_EFLAGS_OF) =20 +#define X86_EFLAGS_ALL \ + (X86_EFLAGS_ARITH_MASK | X86_EFLAGS_TF | X86_EFLAGS_IF | \ + X86_EFLAGS_DF | X86_EFLAGS_OF | X86_EFLAGS_IOPL | \ + X86_EFLAGS_NT | X86_EFLAGS_RF | X86_EFLAGS_VM | \ + X86_EFLAGS_AC | X86_EFLAGS_VIF | X86_EFLAGS_VIP | \ + X86_EFLAGS_ID) + /* * Intel CPU flags in CR0 */ diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index 9a11a0a16b4e..075a3646c2a3 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -1024,7 +1024,7 @@ static int __init dom0_construct(const struct boot_do= main *bd) regs->rip =3D parms.virt_entry; regs->rsp =3D vstack_end; regs->rsi =3D vstartinfo_start; - regs->eflags =3D X86_EFLAGS_IF; + regs->eflags =3D X86_EFLAGS_IF | X86_EFLAGS_MBS; =20 /* * We don't call arch_set_info_guest(), so some initialisation needs d= oing diff --git a/xen/arch/x86/pv/iret.c b/xen/arch/x86/pv/iret.c index d3a1fb2c685b..39ce316b8d91 100644 --- a/xen/arch/x86/pv/iret.c +++ b/xen/arch/x86/pv/iret.c @@ -80,8 +80,9 @@ long do_iret(void) =20 regs->rip =3D iret_saved.rip; regs->cs =3D iret_saved.cs | 3; /* force guest privilege */ - regs->rflags =3D ((iret_saved.rflags & ~(X86_EFLAGS_IOPL|X86_EFLAGS_VM= )) - | X86_EFLAGS_IF); + regs->rflags =3D ((iret_saved.rflags & X86_EFLAGS_ALL & + ~(X86_EFLAGS_IOPL | X86_EFLAGS_VM)) | + X86_EFLAGS_IF | X86_EFLAGS_MBS); regs->rsp =3D iret_saved.rsp; regs->ss =3D iret_saved.ss | 3; /* force guest privilege */ =20 @@ -143,7 +144,8 @@ int compat_iret(void) if ( VM_ASSIST(v->domain, architectural_iopl) ) v->arch.pv.iopl =3D eflags & X86_EFLAGS_IOPL; =20 - regs->eflags =3D (eflags & ~X86_EFLAGS_IOPL) | X86_EFLAGS_IF; + regs->eflags =3D ((eflags & X86_EFLAGS_ALL & ~X86_EFLAGS_IOPL) | + X86_EFLAGS_IF | X86_EFLAGS_MBS); =20 if ( unlikely(eflags & X86_EFLAGS_VM) ) { --=20 2.39.5 From nobody Tue Mar 3 03:25:04 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1772234273; cv=none; d=zohomail.com; s=zohoarc; b=fi1U2N+8iBaRyVwms7bpw6T0RzBxmhSH7YFkiPzcNE2ySXq1DOPT0Wz1wc/M7FnjWBqmhk+ryJ7HdmPj49cbwdN2jVLRhCyTySLY3QXz5SMhWPdpw+Mlgw7VeAWrFsNSfSjDdK8Y/Z99rnvDpRd4RLTUhy6LxwuiCNG6eEbip14= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772234273; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=15zWx1qA8rFF4HWlAuchK/hb06gvUooknaZohCqKUPM=; b=Rq9DerRnXBo+epF4Z5JR074iH0zT5fHnoLp8PpsXDJrFJqMWknRl6a7XS3yROX+X1tePqHWmdOdX6ccC1unm67FLMVJQwf9CDzcvHrlMMuUOqGFaRNgWTolqWtvfb/sSaYpZH4sk/h8a+CZO7J5d4Soyisv0hDqe8TwJ/Zt1Paw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1772234273119388.0657853928493; Fri, 27 Feb 2026 15:17:53 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1243232.1543260 (Exim 4.92) (envelope-from ) id 1vw75N-0007S2-Tm; Fri, 27 Feb 2026 23:17:29 +0000 Received: by outflank-mailman (output) from mailman id 1243232.1543260; Fri, 27 Feb 2026 23:17:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw75N-0007Qw-R3; Fri, 27 Feb 2026 23:17:29 +0000 Received: by outflank-mailman (input) for mailman id 1243232; Fri, 27 Feb 2026 23:17:29 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vw74t-0001Do-21 for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 23:16:59 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 68457e39-1432-11f1-9ccf-f158ae23cfc8; Sat, 28 Feb 2026 00:16:55 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-4398f8e2837so2228203f8f.1 for ; Fri, 27 Feb 2026 15:16:55 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70e8e8sm9680306f8f.10.2026.02.27.15.16.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 15:16:52 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 68457e39-1432-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772234215; x=1772839015; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=15zWx1qA8rFF4HWlAuchK/hb06gvUooknaZohCqKUPM=; b=gA5HPosuZY0sgr9RKW7vL/IlCwdrJsKS0i2R5ajdi7HQaaTgB5jVqb1PYgC5P1Rq+T ZAHEHOXzouLrhKkjPhAdWcDJ5CLk8u1QXGKuJJEnGn1f/GAFVdLcd3brameTli/IJ6rW C/oyhcPeLzHWSkrbP+8YcnNuVOm8mYuqg1+mM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772234215; x=1772839015; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=15zWx1qA8rFF4HWlAuchK/hb06gvUooknaZohCqKUPM=; b=gPkz2llYAEJtMs8F3OCQtis6W9CC767+rD0yoxQ1ciLcoYObdsFpCGMx+1IqpEx0O0 Luk84Alkoau1rBBxRk0YtRU44JIIm4Nnfj2EyA3U/RAUeRLDKHqU9zjPHYI0jJYslveO uw5pWhuDFY0tAf53q0zrQQKiyWIuxR0MOo+DwVgDHCXn6cxiOYIEE9mXeKm4TyUgHxLJ X8WWdxSOW6BWUA23OYsrUqk/JERcHXK/QBGCMqig2yRhfZvK608g8/1DLhhohRMHxc3j d6Hy2fVf33nnCxtH7Y4ysIxIqDUCs5jugz79L+Bf7+JM0c7Y1Nei3JsSAYpxo4azm61s B8VQ== X-Gm-Message-State: AOJu0YzM3uzxaAEnSyJR1Of4Im9hzqd2bkMpaY1UeKe8oT4OSiLyw1DX hCRsH1a2roj5b/jVGFvHOyWmJxL9Y8JLwHfXyACVlFkWK8vKLFC6VUTNtZ/wNO/Y9CNx0H3bPoO e6XYr X-Gm-Gg: ATEYQzw+p6xljYYIBunjpviBiMAkoh8JYTGzNyTZ+2hqDn5gIcHEgz9i2cl/bb+gelQ grbgK+KI0s6hJ9CaPEJAlVD7x8bXHtCbX3kOHaiyDVEBBHhW2Pfnw4/9pJDzpvAWPISSM0S3s9U R73vvDhrRXtAVPs9H2pDWKC49nbmbKT2fZQ7FgNXh6JxmthFU/AdJLS73U2aNcwaUprhUGZqSqi paycop1BDkNc+FBEQwo35Z6pXQdUDsmxgs0skAvV5Rf2nJCHOArHM7ARlGo9eKVGnEou8981lXW fBAHHEvQSN2rYS427Sn2xVxIa+P3/9GbiTIc3Jbtmj/Y+d5252cmHXvNohuYuY4wO6KZFZ/TG3E yDJqNxfcQlb8fjwDJG4yxDKaxYIHRWwshD5pbAHHzsqRJrdcI4ItKFUw3Ea48xJYWRyVG2osKtw PjuiRrLqELhDO3ytfSy6IjaKdXM6aDsfhJaK0IdyVmbQEh4igasXYtp/HxmQQmFoRN6rtQezU= X-Received: by 2002:a05:6000:603:b0:432:a9db:f9a2 with SMTP id ffacd0b85a97d-4399de2b52amr8236751f8f.41.1772234214125; Fri, 27 Feb 2026 15:16:54 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4 14/14] x86/traps: Use fatal_trap() for #UD and #GP Date: Fri, 27 Feb 2026 23:16:36 +0000 Message-Id: <20260227231636.3955109-15-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-1-andrew.cooper3@citrix.com> References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1772234274438158500 This renders the diagnostics in a more uniform way. Signed-off-by: Andrew Cooper Acked-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 v4: * New PF and CP are more complicated and not converted yet. --- xen/arch/x86/traps.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index e2c35a046e6b..c04ab484ad27 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1375,8 +1375,7 @@ void asmlinkage do_invalid_op(struct cpu_user_regs *r= egs) if ( likely(extable_fixup(regs, true)) ) return; =20 - show_execution_state(regs); - panic("FATAL TRAP: vector =3D %d (invalid opcode)\n", X86_EXC_UD); + fatal_trap(regs, false); } =20 void asmlinkage do_int3(struct cpu_user_regs *regs) @@ -1475,8 +1474,7 @@ void do_general_protection(struct cpu_user_regs *regs) return; =20 hardware_gp: - show_execution_state(regs); - panic("GENERAL PROTECTION FAULT\n[error_code=3D%04x]\n", regs->error_c= ode); + fatal_trap(regs, false); } =20 #ifdef CONFIG_PV --=20 2.39.5