All of lore.kernel.org
 help / color / mirror / Atom feed
From: kbuild test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: [joro:sev-es-client-v5.6-rc1 63/63] arch/x86/entry/entry_64.S:1485: Error: no such instruction: `sev_es_nmi_complete'
Date: Sat, 15 Feb 2020 16:23:58 +0800	[thread overview]
Message-ID: <202002151656.NT3GDyoB%lkp@intel.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 5380 bytes --]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git sev-es-client-v5.6-rc1
head:   857e3c24419f15e1295dffd21744b22071089b54
commit: 857e3c24419f15e1295dffd21744b22071089b54 [63/63] x86/sev-es: Add NMI state tracking
config: x86_64-randconfig-s0-20200215 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-4) 7.5.0
reproduce:
        git checkout 857e3c24419f15e1295dffd21744b22071089b54
        # save the attached .config to linux build tree
        make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arch/x86/entry/entry_64.S: Assembler messages:
>> arch/x86/entry/entry_64.S:1485: Error: no such instruction: `sev_es_nmi_complete'
   arch/x86/entry/entry_64.S:1612: Error: no such instruction: `sev_es_nmi_complete'
   arch/x86/entry/entry_64.S:1705: Error: no such instruction: `sev_es_nmi_complete'

vim +1485 arch/x86/entry/entry_64.S

  1389	
  1390	/*
  1391	 * Runs on exception stack.  Xen PV does not go through this path at all,
  1392	 * so we can use real assembly here.
  1393	 *
  1394	 * Registers:
  1395	 *	%r14: Used to save/restore the CR3 of the interrupted context
  1396	 *	      when PAGE_TABLE_ISOLATION is in use.  Do not clobber.
  1397	 */
  1398	SYM_CODE_START(nmi)
  1399		UNWIND_HINT_IRET_REGS
  1400	
  1401		/*
  1402		 * We allow breakpoints in NMIs. If a breakpoint occurs, then
  1403		 * the iretq it performs will take us out of NMI context.
  1404		 * This means that we can have nested NMIs where the next
  1405		 * NMI is using the top of the stack of the previous NMI. We
  1406		 * can't let it execute because the nested NMI will corrupt the
  1407		 * stack of the previous NMI. NMI handlers are not re-entrant
  1408		 * anyway.
  1409		 *
  1410		 * To handle this case we do the following:
  1411		 *  Check the a special location on the stack that contains
  1412		 *  a variable that is set when NMIs are executing.
  1413		 *  The interrupted task's stack is also checked to see if it
  1414		 *  is an NMI stack.
  1415		 *  If the variable is not set and the stack is not the NMI
  1416		 *  stack then:
  1417		 *    o Set the special variable on the stack
  1418		 *    o Copy the interrupt frame into an "outermost" location on the
  1419		 *      stack
  1420		 *    o Copy the interrupt frame into an "iret" location on the stack
  1421		 *    o Continue processing the NMI
  1422		 *  If the variable is set or the previous stack is the NMI stack:
  1423		 *    o Modify the "iret" location to jump to the repeat_nmi
  1424		 *    o return back to the first NMI
  1425		 *
  1426		 * Now on exit of the first NMI, we first clear the stack variable
  1427		 * The NMI stack will tell any nested NMIs at that point that it is
  1428		 * nested. Then we pop the stack normally with iret, and if there was
  1429		 * a nested NMI that updated the copy interrupt stack frame, a
  1430		 * jump will be made to the repeat_nmi code that will handle the second
  1431		 * NMI.
  1432		 *
  1433		 * However, espfix prevents us from directly returning to userspace
  1434		 * with a single IRET instruction.  Similarly, IRET to user mode
  1435		 * can fault.  We therefore handle NMIs from user space like
  1436		 * other IST entries.
  1437		 */
  1438	
  1439		ASM_CLAC
  1440	
  1441		/* Use %rdx as our temp variable throughout */
  1442		pushq	%rdx
  1443	
  1444		testb	$3, CS-RIP+8(%rsp)
  1445		jz	.Lnmi_from_kernel
  1446	
  1447		/*
  1448		 * NMI from user mode.  We need to run on the thread stack, but we
  1449		 * can't go through the normal entry paths: NMIs are masked, and
  1450		 * we don't want to enable interrupts, because then we'll end
  1451		 * up in an awkward situation in which IRQs are on but NMIs
  1452		 * are off.
  1453		 *
  1454		 * We also must not push anything to the stack before switching
  1455		 * stacks lest we corrupt the "NMI executing" variable.
  1456		 */
  1457	
  1458		swapgs
  1459		cld
  1460		FENCE_SWAPGS_USER_ENTRY
  1461		SWITCH_TO_KERNEL_CR3 scratch_reg=%rdx
  1462		movq	%rsp, %rdx
  1463		movq	PER_CPU_VAR(cpu_current_top_of_stack), %rsp
  1464		UNWIND_HINT_IRET_REGS base=%rdx offset=8
  1465		pushq	5*8(%rdx)	/* pt_regs->ss */
  1466		pushq	4*8(%rdx)	/* pt_regs->rsp */
  1467		pushq	3*8(%rdx)	/* pt_regs->flags */
  1468		pushq	2*8(%rdx)	/* pt_regs->cs */
  1469		pushq	1*8(%rdx)	/* pt_regs->rip */
  1470		UNWIND_HINT_IRET_REGS
  1471		pushq   $-1		/* pt_regs->orig_ax */
  1472		PUSH_AND_CLEAR_REGS rdx=(%rdx)
  1473		ENCODE_FRAME_POINTER
  1474	
  1475		/*
  1476		 * At this point we no longer need to worry about stack damage
  1477		 * due to nesting -- we're on the normal thread stack and we're
  1478		 * done with the NMI stack.
  1479		 */
  1480	
  1481		movq	%rsp, %rdi
  1482		movq	$-1, %rsi
  1483		call	do_nmi
  1484	
> 1485		SEV_ES_NMI_COMPLETE
  1486	
  1487		/*
  1488		 * Return back to user mode.  We must *not* do the normal exit
  1489		 * work, because we don't want to enable interrupts.
  1490		 */
  1491		jmp	swapgs_restore_regs_and_return_to_usermode
  1492	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 40540 bytes --]

                 reply	other threads:[~2020-02-15  8:23 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=202002151656.NT3GDyoB%lkp@intel.com \
    --to=lkp@intel.com \
    --cc=kbuild-all@lists.01.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.