Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Li, Xin3" <xin3.li@intel.com>
To:     Peter Zijlstra <peterz@infradead.org>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
        "Lutomirski, Andy" <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "H . Peter Anvin" <hpa@zytor.com>,
        "Gross, Jurgen" <jgross@suse.com>,
        "Ostrovsky, Boris" <boris.ostrovsky@oracle.com>
Subject: RE: [RFC PATCH 1/1] x86/traps: Get rid of exception handlers' second
 argument error code
Thread-Topic: [RFC PATCH 1/1] x86/traps: Get rid of exception handlers' second
 argument error code
Thread-Index: AQHZxq1luoPee3LE20qWOZPEmJublq/Z6zyAgAB3ZVA=
Date:   Fri, 4 Aug 2023 17:35:11 +0000
Message-ID: <SA1PR11MB67349385C20E8D3B0C960432A809A@SA1PR11MB6734.namprd11.prod.outlook.com>
References: <20230804075734.8372-1-xin3.li@intel.com>
 <20230804101321.GH214207@hirez.programming.kicks-ass.net>
In-Reply-To: <20230804101321.GH214207@hirez.programming.kicks-ass.net>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?KwPsvvqJE/yjGL6oYxYxvYK70dJM3vfF8TS5+yo5alHwMpsJvX3iAbYXzFwU?=
 =?us-ascii?Q?KdMJoNOydubX3XPBVStaT6vZ20EVa6efvDQoId9fzc6NQEzeHfoKS2YtbiWc?=
 =?us-ascii?Q?YgZRmxwmE1+uZDfRbpPt5x4rPA9Feg/3EdmYxQgklulCP7AtUQDwz904Hwe1?=
 =?us-ascii?Q?kMiuRr1uA/lY4BJIZ700UnhKcSjzwh85NV2VOok3+kPsuF1514pystHUXa3Y?=
 =?us-ascii?Q?+t3ZT4Q80pogDSxQRcZx3CuvpRGxgTltmVCWYuVHEbdgqYnta+vrMLfSZLXF?=
 =?us-ascii?Q?pKUtCpQS+r3YjCuFlB2fV0eeD4rgB9dGJyLvkhK+D69bDInqSSStjNKBv+cz?=
 =?us-ascii?Q?b12Lgu7b0JhtTGzeceN0DBdpjabtLlSEkGQ/RiuE+Ofi56n6IXoXAr57vsuv?=
 =?us-ascii?Q?ax0BbyQINygOvPgmBPJ3L7jBStMg13Ej1g+K7YaX1/+xhCmiOAVRSPjZFnW0?=
 =?us-ascii?Q?DHzFOge3mXfhFUt3dYuBrqLAlqJqP/rKj1UZyFY1P7ED+SLL4wfo8oa1tqV2?=
 =?us-ascii?Q?sqBUyb6+w5o1RdCVDs6XLwoSFT932lY+WEa5AjaXLu7akUtK7xVRFuVMyu3F?=
 =?us-ascii?Q?KTRbIM0tFgKrd+ru2kXchCdgN/g5LOv8teTX2eCv6iRerKIZ0qYraqipAKBd?=
 =?us-ascii?Q?nSrb6igptDquMnG7ZgIsJWxbmc8kkBjVP9ruLzl9QcHgJlm37iwN5ANB6eeo?=
 =?us-ascii?Q?5mbjnvbxDd9U610gy0VO2Iq/944NbEyBemYUcCc785yVXFMh0G8knMvA5XZa?=
 =?us-ascii?Q?aG1bcfNEfnDUhcZiIsBaOMnX+kWMGx+0Eq0GoOqySj4WKERlNOa3ODMRueyS?=
 =?us-ascii?Q?lUbwcAAqNGDyw1ixi8p4Zv14myjmaU8XjQbw8snmYRvbo6WVkMsU+zxTawsP?=
 =?us-ascii?Q?cY/z2l5v+XilTNqtoP7mIlaF/xiYEdCZ+4THmIAtLBUJ6f89h+w41/WbLEyF?=
 =?us-ascii?Q?KE/1GXRGKQkBvIysQnd+RcAjr1MxKFd17T5VJn9G8tjo4N704fhXzE+hOGiu?=
 =?us-ascii?Q?h0ZTEpRVyXFOq78NtNPh1cm+y/N3QqS0SYL1R5aNTf2Wz/krGo6WjF11wQxH?=
 =?us-ascii?Q?TBreVpN/+rIGYx8q+szEcQyvnwqebHh6v6qL2EjAc4bDZkmZvI8Kfa64MTVM?=
 =?us-ascii?Q?d6WUheRxjojHbawJH65JI5jxssOwze+CUtJCzuCsO9A5bmvMHVSzI1oSRmcs?=
 =?us-ascii?Q?g/UjtDlSelRpAik5oNxBEDlriWkEqs2LwjDMjAfWyo5+UOQdxA/rX7eun0mh?=
 =?us-ascii?Q?1+0TLRRviPpTFI/dBW9Fzd5yuHza3MIDmQ/jZyvffkiW5fLUJhdxm8ny11lZ?=
 =?us-ascii?Q?1mrvhCXYfZmzg0bTFS9PVozEdNouhZtsKRIM2ovmTaz3GMa0UPjwWXnkw8M+?=
 =?us-ascii?Q?+HcGj6xmewbzU2mAu9c10rh+HMk1qqmMQjkgjgjqC/+kp//KljijDwVkJcoG?=
 =?us-ascii?Q?yruB3BD0L1qkW3czcvQDYCAVieaEnM8IMPuF40ZebchvUa8Czf5AZpKOqqI7?=
 =?us-ascii?Q?OWQxGP7ON55TL8lqqj+HFX3KjclH/8TPpzmD6HfvohZlNGNPHp5ljDS5yCiQ?=
 =?us-ascii?Q?2zOnEUQ8mUGctXD97cI=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6734.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 96d1cd66-62fc-4813-6e5f-08db9511277a
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2023 17:35:11.1752
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EMTATcikUJ4zLGXp5lfiDx8Lqihoa+4aJ7DHvW+i/k+1tnu+vLhDiUaksF813HXxXNEHGXLFUH6eZgAcKtQv+w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB6943
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > The IDT event delivery of X86_TRAP_DF, X86_TRAP_TS, X86_TRAP_NP,
> > X86_TRAP_SS, X86_TRAP_GP, X86_TRAP_AC and X86_TRAP_CP pushes an error
> > code into the orig_ax member of the pt_regs structure, and the error
> > code is passed as the second argument of their C-handlers, although
> > the pt_regs structure is already passed as the first argument.
> >
> > The asm entry code of such faults does the following
> >
> >   movq ORIG_RAX(%rsp), %rsi	/* get error code into 2nd argument*/
> >   movq $-1, ORIG_RAX(%rsp)	/* no syscall to restart */
> >
> > to set the orig_ax member to -1 just before calling the C-handler.
> >
> > In addition, the IRQ entry code uses the second error code argument as
> > its IRQ vector, as the IRQ asm entry code pushes its IRQ vector into
> > the orig_ax member.
> >
> > The commit d99015b1abbad ("x86: move entry_64.S register saving out of
> > the macros") introduced the changes to set orig_ax to -1, but I can't
> > see why it's required. Our tests on x86_64 and x86_32 seem fine if
> > orig_ax is left unchanged instead of set to -1.
>=20
> That means that SYSCALL_NUM(regs) get to be garbage; or something like th=
at.

I find SYSCALL_NUM(regs) in tools/testing/selftests/seccomp/seccomp_bpf.c,
but nothing obvious to me.

I think it's clear that once exceptions and IRQs are handled, the original
context will be fully recovered in a normal case.

Is it related to preemption after such a event?

I must have missed something; can you please elaborate it?