[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [RFC PATCH 1/1] x86/traps: Get rid of exception handlers' second argument error code


  • To: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
  • From: "Li, Xin3" <xin3.li@xxxxxxxxx>
  • Date: Fri, 4 Aug 2023 17:35:11 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ubv7enYxLzTXmgjsMDcuRLrQdCBhlZzE3KL1OOJZcw4=; b=G6e0aL1DtQHWOvwCJIeyi24pDTCd/GTFDlsjYvKtlTlzIl4bZPR2fVht/umQtvwWAVcBv2DeYJvreuQcRMK9OKXhinnxJzLzffLPzdoJz9SDyrqzOJjBIy4Rk5s/+ui419DXDNmMiuwlmYJV3nPOlNk19wWhv0/d2rDYy/PIn3/C+yzekTWgJVcSf8JxwZJv/3TOld4AgizgGUAM31XhPSF5WnWL8k6bf7nYuetKm1zAQaVRG2cbI/8+vBlycZjKUNFHTT9xcmqqpmN2HXXkERZLcQY+eyVT9+P/vho0PR6ZCFMxREBQ5plmGw/0n2q2T3WH53lXghLzhgUAeUZdYw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cMcz8Um5w3krvSYNtfw/RXzY59g7nTdCVvQxy0+0Zsys0Y7kjmgQs746LsZFpDM9kz56YeC79neKxUQkTbYNck2WFipGZhLaOKgieaR2FEFIho6fhPA3TZBUWI3shtzAMUW2XqKfqCEuW3PEDe7en4LB9mYyKkawi7HSwkM2l3sscB4dN3IuW2yt71UGw3ZR119UUjJm1iEoLXi3PVozqgGltP8NUn7WT70W/QwZTvPL+b7qImomrkfBH8AOseee2DdQDESE7kNxZam7fJH7j96mMB6ibEgSGqqdW7KVHEiv8Mezl5WA3B3Q0E3I+41RjMMIgy5Zckrddrzy25UJow==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com;
  • Cc: "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Lutomirski, Andy" <luto@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, "x86@xxxxxxxxxx" <x86@xxxxxxxxxx>, "H . Peter Anvin" <hpa@xxxxxxxxx>, "Gross, Jurgen" <jgross@xxxxxxxx>, "Ostrovsky, Boris" <boris.ostrovsky@xxxxxxxxxx>
  • Delivery-date: Fri, 04 Aug 2023 17:35:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHZxq1luoPee3LE20qWOZPEmJublq/Z6zyAgAB3ZVA=
  • Thread-topic: [RFC PATCH 1/1] x86/traps: Get rid of exception handlers' second argument error code

> > 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.
> 
> That means that SYSCALL_NUM(regs) get to be garbage; or something like that.

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?



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.