mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Xin Li <xin@zytor.com>
To: Ethan Zhao <etzhao@outlook.com>, "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	dave.hansen@linux.intel.com, tglx@linutronix.de,
	stable@vger.kernel.org, Ethan Zhao <haifeng.zhao@linux.intel.com>
Subject: Re: BUG ? exc_page_fault() was optimized out of fred_hwexc() by gcc with default kernel build option (-O2).
Date: Sat, 18 Jan 2025 10:34:02 -0800	[thread overview]
Message-ID: <ff96c2db-2424-4d11-bfbd-e5b131a5d025@zytor.com> (raw)
In-Reply-To: <TYZPR03MB88013AABBBC2B40F7B955825D1E52@TYZPR03MB8801.apcprd03.prod.outlook.com>

On 1/18/2025 5:50 AM, Ethan Zhao wrote:
> Hi, Xin, Peter
> 
>    While checking the asm code of arch/x86/entry/entry_fred.o about 
> function fred_hwexc(),
> found the code was generated as following :
> 
> 0000000000000200 <fred_hwexc.constprop.0>:
>   200:   0f b6 87 a4 00 00 00    movzbl 0xa4(%rdi),%eax
>   207:   3c 0e                   cmp    $0xe,%al /* match X86_TRAP_PF */
>   209:   75 05                   jne    210 <fred_hwexc.constprop.0+0x10>
>   20b:   e9 00 00 00 00          jmp    210 <fred_hwexc.constprop.0+0x10>
>   210:   3c 0b                   cmp    $0xb,%al
>   212:   74 6a                   je     27e <fred_hwexc.constprop.0+0x7e>
>   214:   77 17                   ja     22d <fred_hwexc.constprop.0+0x2d>
>   216:   3c 06                   cmp    $0x6,%al
>   218:   0f 84 83 00 00 00       je     2a1 <fred_hwexc.constprop.0+0xa1>
>   21e:   76 29                   jbe    249 <fred_hwexc.constprop.0+0x49>
>   220:   3c 08                   cmp    $0x8,%al
>   222:   74 78                   je     29c <fred_hwexc.constprop.0+0x9c>
>   224:   3c 0a                   cmp    $0xa,%al
>   226:   75 18                   jne    240 <fred_hwexc.constprop.0+0x40>
>   228:   e9 00 00 00 00          jmp    22d <fred_hwexc.constprop.0+0x2d>
>   22d:   3c 11                   cmp    $0x11,%al
>   22f:   74 66                   je     297 <fred_hwexc.constprop.0+0x97>
>   231:   76 2c                   jbe    25f <fred_hwexc.constprop.0+0x5f>
>   233:   3c 13                   cmp    $0x13,%al
>   235:   74 5b                   je     292 <fred_hwexc.constprop.0+0x92>
>   237:   3c 15                   cmp    $0x15,%al
>   239:   75 1b                   jne    256 <fred_hwexc.constprop.0+0x56>
>   23b:   e9 00 00 00 00          jmp    240 <fred_hwexc.constprop.0+0x40>
>   240:   3c 07                   cmp    $0x7,%al
>   242:   75 49                   jne    28d <fred_hwexc.constprop.0+0x8d>
>   244:   e9 00 00 00 00          jmp    249 <fred_hwexc.constprop.0+0x49>
>   249:   3c 01                   cmp    $0x1,%al
>   24b:   74 3b                   je     288 <fred_hwexc.constprop.0+0x88>
>   24d:   3c 05                   cmp    $0x5,%al
>   24f:   75 1b                   jne    26c <fred_hwexc.constprop.0+0x6c>
>   251:   e9 00 00 00 00          jmp    256 <fred_hwexc.constprop.0+0x56>
>   256:   3c 12                   cmp    $0x12,%al
>   258:   75 33                   jne    28d <fred_hwexc.constprop.0+0x8d>
>   25a:   e9 00 00 00 00          jmp    25f <fred_hwexc.constprop.0+0x5f>
> 
> seems the following calling to exc_page_fault() was optimized out from 
> fred_hwexc() by gcc,
> 
> if(likely(regs->fred_ss.vector==X86_TRAP_PF))
> returnexc_page_fault(regs,error_code);
> 
> gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
> 
> GNU objdump (GNU Binutils) 2.43
> 
> 
> default kernel config.
> .config:CONFIG_X86_FRED=y
> 
> my understanding, -O2 is the default kernel KBUILD_CFLAGS
> So, Are there any workaround needed to make the kernel works with 
> default build ?
> or just as Peter said in another loop, manually loading some event bits 
> to make the
> over-smart gcc behave normally ?or fall back to -O(ption)0 ?
> 
> Any idea, much appreciated !

This is an optimization done in the original code:

static noinstr void fred_hwexc(struct pt_regs *regs, unsigned long 
error_code)
{
         /* Optimize for #PF. That's the only exception which matters 
performance wise */
         if (likely(regs->fred_ss.vector == X86_TRAP_PF))
                 return exc_page_fault(regs, error_code);

         switch (regs->fred_ss.vector) {


  reply	other threads:[~2025-01-18 18:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-18 13:50 Ethan Zhao
2025-01-18 18:34 ` Xin Li [this message]
2025-01-19  0:42   ` Ethan Zhao
2025-01-19  9:43 ` Ethan Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ff96c2db-2424-4d11-bfbd-e5b131a5d025@zytor.com \
    --to=xin@zytor.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=etzhao@outlook.com \
    --cc=haifeng.zhao@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome