[intel-tdx:guest-unaccepted-memory 2/17] arch/x86/coco/tdx/tdx.c:167:30: warning: format '%d' expects argument of type 'int', but argument 2 has type 'u64' {aka 'long long unsigned int'}

[kernel test robot <lkp@intel.com>]

tree:   https://github.com/intel/tdx.git guest-unaccepted-memory
head:   7a902d05477ac272558ba731d903c6b0c9d72903
commit: b79b8d6d1f803ccb288402963fe31b887438e5fc [2/17] x86/tdx: Clarify RIP adjustments in #VE handler
config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20220614/202206141529.wEmcF0KX-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce (this is a W=1 build):
        # https://github.com/intel/tdx/commit/b79b8d6d1f803ccb288402963fe31b887438e5fc
        git remote add intel-tdx https://github.com/intel/tdx.git
        git fetch --no-tags intel-tdx guest-unaccepted-memory
        git checkout b79b8d6d1f803ccb288402963fe31b887438e5fc
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash arch/x86/coco/tdx/

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

All warnings (new ones prefixed by >>):

   In file included from arch/x86/include/asm/bug.h:87,
                    from include/linux/bug.h:5,
                    from include/linux/cpumask.h:14,
                    from arch/x86/include/asm/cpumask.h:5,
                    from arch/x86/include/asm/msr.h:11,
                    from arch/x86/include/asm/processor.h:22,
                    from arch/x86/include/asm/cpufeature.h:5,
                    from include/linux/cpufeature.h:13,
                    from arch/x86/coco/tdx/tdx.c:7:
   arch/x86/coco/tdx/tdx.c: In function 've_instr_len':
>> arch/x86/coco/tdx/tdx.c:167:30: warning: format '%d' expects argument of type 'int', but argument 2 has type 'u64' {aka 'long long unsigned int'} [-Wformat=]
     167 |                 WARN_ONCE(1, "Unexpected #VE-type: %d\n", ve->exit_reason);
         |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~
         |                                                             |
         |                                                             u64 {aka long long unsigned int}
   include/asm-generic/bug.h:105:31: note: in definition of macro '__WARN_printf'
     105 |                 __warn_printk(arg);                                     \
         |                               ^~~
   include/linux/once_lite.h:19:25: note: in expansion of macro 'WARN'
      19 |                         func(__VA_ARGS__);                              \
         |                         ^~~~
   include/asm-generic/bug.h:151:9: note: in expansion of macro 'DO_ONCE_LITE_IF'
     151 |         DO_ONCE_LITE_IF(condition, WARN, 1, format)
         |         ^~~~~~~~~~~~~~~
   arch/x86/coco/tdx/tdx.c:167:17: note: in expansion of macro 'WARN_ONCE'
     167 |                 WARN_ONCE(1, "Unexpected #VE-type: %d\n", ve->exit_reason);
         |                 ^~~~~~~~~
   arch/x86/coco/tdx/tdx.c:167:53: note: format string is defined here
     167 |                 WARN_ONCE(1, "Unexpected #VE-type: %d\n", ve->exit_reason);
         |                                                    ~^
         |                                                     |
         |                                                     int
         |                                                    %lld


vim +167 arch/x86/coco/tdx/tdx.c

   126	
   127	/*
   128	 * TDX module spec states that #VE may be injected by the Intel TDX module in
   129	 * several cases:
   130	 *
   131	 *  - Emulation of the architectural #VE injection on EPT violation;
   132	 *
   133	 *  - As a result of guest TD execution of a disallowed instruction,
   134	 *    a disallowed MSR access, or CPUID virtualization;
   135	 *
   136	 *  - A notification to the guest TD about anomalous behavior;
   137	 *
   138	 * The last one is opt-in and is not used by the kernel.
   139	 *
   140	 * Intel Software Developer's Manual describes cases when instruction length
   141	 * field can be used in section "Information for VM Exits Due to Instruction
   142	 * Execution".
   143	 *
   144	 * For TDX, it ultimately means GET_VEINFO provides reliable instruction length
   145	 * information if #VE occurred due to instruction execution, but not for EPT
   146	 * violations.
   147	 */
   148	static int ve_instr_len(struct ve_info *ve)
   149	{
   150		switch (ve->exit_reason) {
   151		case EXIT_REASON_HLT:
   152		case EXIT_REASON_MSR_READ:
   153		case EXIT_REASON_MSR_WRITE:
   154		case EXIT_REASON_CPUID:
   155		case EXIT_REASON_IO_INSTRUCTION:
   156			/* It is safe to use ve->instr_len for #VE due instructions */
   157			return ve->instr_len;
   158		case EXIT_REASON_EPT_VIOLATION:
   159			/*
   160			 * For EPT violations, ve->insn_len is not defined. For those,
   161			 * the kernel must decode instructions manually and should not
   162			 * be using this function.
   163			 */
   164			WARN_ONCE(1, "ve->instr_len is not defined for EPT violations");
   165			return 0;
   166		default:
 > 167			WARN_ONCE(1, "Unexpected #VE-type: %d\n", ve->exit_reason);
   168			return ve->instr_len;
   169		}
   170	}
   171	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp