On 6/11/23 21:25, Michael Roth wrote:
> + /*
> + * If the RMP entry at the faulting pfn was not assigned, then not sure
> + * what caused the RMP violation. To get some useful debug information,
> + * iterate through the entire 2MB region, and dump the RMP entries if
> + * one of the bit in the RMP entry is set.
> + */
> + pfn = pfn & ~(PTRS_PER_PMD - 1);
> + pfn_end = pfn + PTRS_PER_PMD;
> +
> + while (pfn < pfn_end) {
> + ret = __snp_lookup_rmpentry(pfn, &e, &level);
> + if (ret) {
> + pr_info("Failed to read RMP entry for PFN 0x%llx\n", pfn);
> + pfn++;
> + continue;
> + }
> +
> + if (e.low || e.high)
> + pr_info("RMPEntry paddr 0x%llx: [high=0x%016llx low=0x%016llx]\n",
> + pfn << PAGE_SHIFT, e.high, e.low);
> + pfn++;
> + }
> +}
Dumping 511 lines of (possible) junk into the dmesg buffer seems a _bit_
rude here. I can see dumping out the 2M RMP entry, but not the other 510.
This also destroys the information about which pfn was being targeted
for the dump in the first place. That seems unfortunate.
