From: kernel test robot <lkp@intel.com>
To: Brijesh Singh <brijesh.singh@amd.com>
Cc: oe-kbuild-all@lists.linux.dev, kvm-ppc@vger.kernel.org,
cloud-init created default user
<ec2-user@ip-172-31-5-41.eu-west-1.compute.internal>,
Ashish Kalra <ashish.kalra@amd.com>,
Michael Roth <michael.roth@amd.com>
Subject: [agraf-2.6:snp-host-v10 65/108] arch/x86/virt/svm/sev.c:352:6: warning: no previous prototype for 'sev_dump_hva_rmpentry'
Date: Thu, 9 Nov 2023 22:02:30 +0800 [thread overview]
Message-ID: <202311092152.UjfN6FW5-lkp@intel.com> (raw)
tree: https://github.com/agraf/linux-2.6.git snp-host-v10
head: 689d7ab69df8f6bff29bd1dbefe7c07bba52a9ac
commit: 7187f30c29e7c30b39e34bb3ab06ecbf034800ab [65/108] x86/fault: Add helper for dumping RMP entries
config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20231109/202311092152.UjfN6FW5-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231109/202311092152.UjfN6FW5-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/202311092152.UjfN6FW5-lkp@intel.com/
All warnings (new ones prefixed by >>):
arch/x86/virt/svm/sev.c:280:5: warning: no previous prototype for 'snp_lookup_rmpentry' [-Wmissing-prototypes]
280 | int snp_lookup_rmpentry(u64 pfn, bool *assigned, int *level)
| ^~~~~~~~~~~~~~~~~~~
>> arch/x86/virt/svm/sev.c:352:6: warning: no previous prototype for 'sev_dump_hva_rmpentry' [-Wmissing-prototypes]
352 | void sev_dump_hva_rmpentry(unsigned long hva)
| ^~~~~~~~~~~~~~~~~~~~~
vim +/sev_dump_hva_rmpentry +352 arch/x86/virt/svm/sev.c
279
> 280 int snp_lookup_rmpentry(u64 pfn, bool *assigned, int *level)
281 {
282 struct rmpentry e;
283 int ret;
284
285 ret = __snp_lookup_rmpentry(pfn, &e, level);
286 if (ret)
287 return ret;
288
289 *assigned = !!e.assigned;
290 return 0;
291 }
292 EXPORT_SYMBOL_GPL(snp_lookup_rmpentry);
293
294 /*
295 * Dump the raw RMP entry for a particular PFN. These bits are documented in the
296 * PPR for a particular CPU model and provide useful information about how a
297 * particular PFN is being utilized by the kernel/firmware at the time certain
298 * unexpected events occur, such as RMP faults.
299 */
300 static void sev_dump_rmpentry(u64 dumped_pfn)
301 {
302 struct rmpentry e;
303 u64 pfn, pfn_end;
304 int level, ret;
305 u64 *e_data;
306
307 ret = __snp_lookup_rmpentry(dumped_pfn, &e, &level);
308 if (ret) {
309 pr_info("Failed to read RMP entry for PFN 0x%llx, error %d\n",
310 dumped_pfn, ret);
311 return;
312 }
313
314 e_data = (u64 *)&e;
315 if (e.assigned) {
316 pr_info("RMP entry for PFN 0x%llx: [high=0x%016llx low=0x%016llx]\n",
317 dumped_pfn, e_data[1], e_data[0]);
318 return;
319 }
320
321 /*
322 * If the RMP entry for a particular PFN is not in an assigned state,
323 * then it is sometimes useful to get an idea of whether or not any RMP
324 * entries for other PFNs within the same 2MB region are assigned, since
325 * those too can affect the ability to access a particular PFN in
326 * certain situations, such as when the PFN is being accessed via a 2MB
327 * mapping in the host page table.
328 */
329 pfn = ALIGN(dumped_pfn, PTRS_PER_PMD);
330 pfn_end = pfn + PTRS_PER_PMD;
331
332 while (pfn < pfn_end) {
333 ret = __snp_lookup_rmpentry(pfn, &e, &level);
334 if (ret) {
335 pr_info_ratelimited("Failed to read RMP entry for PFN 0x%llx\n", pfn);
336 pfn++;
337 continue;
338 }
339
340 if (e_data[0] || e_data[1]) {
341 pr_info("No assigned RMP entry for PFN 0x%llx, but the 2MB region contains populated RMP entries, e.g.: PFN 0x%llx: [high=0x%016llx low=0x%016llx]\n",
342 dumped_pfn, pfn, e_data[1], e_data[0]);
343 return;
344 }
345 pfn++;
346 }
347
348 pr_info("No populated RMP entries in the 2MB region containing PFN 0x%llx\n",
349 dumped_pfn);
350 }
351
> 352 void sev_dump_hva_rmpentry(unsigned long hva)
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2023-11-09 14:03 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=202311092152.UjfN6FW5-lkp@intel.com \
--to=lkp@intel.com \
--cc=ashish.kalra@amd.com \
--cc=brijesh.singh@amd.com \
--cc=ec2-user@ip-172-31-5-41.eu-west-1.compute.internal \
--cc=kvm-ppc@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=oe-kbuild-all@lists.linux.dev \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).