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
next prev 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.