Messages in this thread | | | From | "Kalra, Ashish" <> | Subject | RE: [PATCH Part2 v6 07/49] x86/sev: Invalid pages from direct map when adding it to RMP table | Date | Mon, 1 Aug 2022 23:57:09 +0000 |
| |
[AMD Official Use Only - General]
Hello Boris,
>> Subject: x86/sev: Invalid pages from direct map when adding it to RMP >> table
>"...: Invalidate pages from the direct map when adding them to the RMP table" Ok
>> +static int restore_direct_map(u64 pfn, int npages) { >> + int i, ret = 0; >> + >> + for (i = 0; i < npages; i++) { >> + ret = set_direct_map_default_noflush(pfn_to_page(pfn + i));
>set_memory_p() ?
You mean set_memory_present() ?
Is there an issue with not using set_direct_map_default_noflush(), it is easier to correlate with this function and it's functionality of restoring the page in the kernel direct map ?
> + if (ret) > + goto cleanup; > + } > + > +cleanup: > + WARN(ret > 0, "Failed to restore direct map for pfn 0x%llx\n", pfn + > +i);
>Warn for each pfn?!
>That'll flood dmesg mightily.
> + return ret; > +} > + > +static int invalid_direct_map(unsigned long pfn, int npages) { > + int i, ret = 0; > + > + for (i = 0; i < npages; i++) { > + ret = set_direct_map_invalid_noflush(pfn_to_page(pfn + i));
>As above, set_memory_np() doesn't work here instead of looping over each page?
Yes, set_memory_np() looks more efficient to use instead of looping over each page.
But again, calling set_direct_map_invalid_noflush() is easier to understand from the calling function's point of view as it correlates to the functionality of invalidating the page from kernel direct map ?
>> + if (val->assigned) { >> + if (invalid_direct_map(pfn, npages)) { >. + pr_err("Failed to unmap pfn 0x%llx pages %d from direct_map\n",
>"Failed to unmap %d pages at pfn 0x... from the direct map\n" Ok.
>> + if (!ret && !val->assigned) { >> + if (restore_direct_map(pfn, npages)) { >> + pr_err("Failed to map pfn 0x%llx pages %d in direct_map\n",
>"Failed to map %d pages at pfn 0x... into the direct map\n" Ok.
Thanks, Ashish
| |