Message ID | 6ecac5e1-2131-44b0-af07-eeacfbd6b522@suse.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | x86: don't open-code max_page calculation nor pfn_to_paddr() | expand |
On 18/12/2023 3:13 pm, Jan Beulich wrote: > As observed by Roger while reviewing a somewhat related change, there's > no need here either to open-code the (largely, i.e. once setup_max_pdx() > was called) fixed relationship between max_pdx and max_page. Further we > can avoid open-coding pfn_to_paddr() here. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1569,7 +1569,7 @@ void asmlinkage __init noreturn __start_ continue; } map_e = e; - e = (pdx_to_pfn(max_pdx - 1) + 1ULL) << PAGE_SHIFT; + e = pfn_to_paddr(max_page); printk(XENLOG_WARNING "Ignoring inaccessible memory range" " %013"PRIx64"-%013"PRIx64"\n", e, map_e);
As observed by Roger while reviewing a somewhat related change, there's no need here either to open-code the (largely, i.e. once setup_max_pdx() was called) fixed relationship between max_pdx and max_page. Further we can avoid open-coding pfn_to_paddr() here. Signed-off-by: Jan Beulich <jbeulich@suse.com>