All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Michal Gorlas <michal.gorlas@9elements.com>,
	Tzung-Bi Shih <tzungbi@kernel.org>,
	Brian Norris <briannorris@chromium.org>,
	Julius Werner <jwerner@chromium.org>
Cc: oe-kbuild-all@lists.linux.dev, marcello.bauer@9elements.com,
	Michal Gorlas <michal.gorlas@9elements.com>,
	chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/3] firmware: coreboot: loader for Linux-owned SMI handler
Date: Fri, 13 Jun 2025 13:21:58 +0800	[thread overview]
Message-ID: <202506131541.RxswGh7u-lkp@intel.com> (raw)
In-Reply-To: <6cfb5bae79c153c54da298c396adb8a28b5e785a.1749734094.git.michal.gorlas@9elements.com>

Hi Michal,

kernel test robot noticed the following build errors:

[auto build test ERROR on chrome-platform/for-next]
[also build test ERROR on chrome-platform/for-firmware-next linus/master v6.16-rc1 next-20250612]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Michal-Gorlas/firmware-coreboot-support-for-parsing-SMM-related-informations-from-coreboot-tables/20250612-221612
base:   https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git for-next
patch link:    https://lore.kernel.org/r/6cfb5bae79c153c54da298c396adb8a28b5e785a.1749734094.git.michal.gorlas%409elements.com
patch subject: [PATCH v1 2/3] firmware: coreboot: loader for Linux-owned SMI handler
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20250613/202506131541.RxswGh7u-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250613/202506131541.RxswGh7u-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202506131541.RxswGh7u-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/firmware/google/mm_loader.c: In function 'place_handler':
>> drivers/firmware/google/mm_loader.c:105:9: error: implicit declaration of function 'wbinvd' [-Wimplicit-function-declaration]
     105 |         wbinvd();
         |         ^~~~~~


vim +/wbinvd +105 drivers/firmware/google/mm_loader.c

    84	
    85	static u32 __init place_handler(void)
    86	{
    87		/*
    88		 * The handler (aka MM blob) has to be placed in low 4GB of the memory.
    89		 * This is because we can not assume that coreboot will be in long mode
    90		 * while trying to copy the blob to SMRAM. Even if so, (can be checked by
    91		 * reading cb_data->mm_info.requires_long_mode_call), it would make our life
    92		 * way too complicated (e.g. no need for shared page table).
    93		 */
    94		size_t entry32_offset;
    95		size_t entry64_offset;
    96		u16 real_mode_seg;
    97		const u32 *rel;
    98		u32 count;
    99		unsigned long phys_base;
   100	
   101		blob_size = mm_payload_size_needed();
   102		shared_buffer = (void *)__get_free_pages(GFP_DMA32, get_order(blob_size));
   103	
   104		memcpy(shared_buffer, mm_blob, blob_size);
 > 105		wbinvd();
   106	
   107		/*
   108		 * Based on arch/x86/realmode/init.c
   109		 * The sole purpose of doing relocations is to be able to calculate the offsets
   110		 * for entry points. While the absolute addresses are not valid anymore after the
   111		 * blob is copied to SMRAM, the distances between sections stay the same, so we
   112		 * can still calculate the correct entry point based on coreboot's bitness.
   113		 */
   114		phys_base = __pa(shared_buffer);
   115		real_mode_seg = phys_base >> 4;
   116		rel = (u32 *)mm_relocs;
   117	
   118		/* 16-bit segment relocations. */
   119		count = *rel++;
   120		while (count--) {
   121			u16 *seg = (u16 *)(shared_buffer + *rel++);
   122			*seg = real_mode_seg;
   123		}
   124	
   125		/* 32-bit linear relocations. */
   126		count = *rel++;
   127		while (count--) {
   128			u32 *ptr = (u32 *)(shared_buffer + *rel++);
   129			*ptr += phys_base;
   130		}
   131	
   132		mm_header =  (struct mm_header *)shared_buffer;
   133	
   134		mm_header->mm_signature = REALMODE_END_SIGNATURE;
   135		mm_header->mm_blob_size = mm_payload_size_needed();
   136	
   137		/* At this point relocations are done and we can do some cool
   138		 * pointer arithmetics to help coreboot determine correct entry
   139		 * point based on offsets.
   140		 */
   141		entry32_offset = mm_header->mm_entry_32 - (unsigned long)shared_buffer;
   142		entry64_offset = mm_header->mm_entry_64 - (unsigned long)shared_buffer;
   143	
   144		mm_header->mm_entry_32 = entry32_offset;
   145		mm_header->mm_entry_64 = entry64_offset;
   146	
   147		return (unsigned long)shared_buffer;
   148	}
   149	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

  parent reply	other threads:[~2025-06-13  5:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12 14:05 [PATCH v1 0/3] firmware: coreboot: Support for System Management Interrupt (SMI) handling in coreboot payload (MM payload concept) Michal Gorlas
2025-06-12 14:05 ` [PATCH v1 1/3] firmware: coreboot: support for parsing SMM related informations from coreboot tables Michal Gorlas
2025-06-12 22:37   ` Brian Norris
2025-06-14 12:53     ` Michal Gorlas
2025-06-16 18:16       ` Brian Norris
2025-06-17  9:37         ` Michal Gorlas
2025-06-12 14:05 ` [PATCH v1 2/3] firmware: coreboot: loader for Linux-owned SMI handler Michal Gorlas
2025-06-12 22:38   ` Brian Norris
2025-06-14 12:59     ` Michal Gorlas
2025-06-16 18:07       ` Brian Norris
2025-06-17 11:39         ` Michal Gorlas
2025-06-13  5:21   ` kernel test robot [this message]
2025-06-12 14:05 ` [PATCH v1 3/3] firmware: coreboot: Linux-owned SMI handler to be loaded by coreboot Michal Gorlas
2025-06-12 22:38   ` Brian Norris
2025-06-13 12:11   ` kernel test robot

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=202506131541.RxswGh7u-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=briannorris@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=jwerner@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcello.bauer@9elements.com \
    --cc=michal.gorlas@9elements.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=tzungbi@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 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.