On 05/10/2016 11:43 AM, Juergen Gross wrote: > On 10/05/16 17:35, Jan Beulich wrote: >>>>> On 10.05.16 at 17:19, <jgr...@suse.com> wrote: >>> On 10/05/16 15:57, Jan Beulich wrote: >>>>>>> On 10.05.16 at 15:39, <boris.ostrov...@oracle.com> wrote: >>>>> I didn't finish unwrapping the stack yesterday. Here it is: >>>>> >>>>> setup_arch -> dmi_scan_machine -> dmi_walk_early -> early_ioremap >>>> Ah, that makes sense. Yet why would early_ioremap() involve an >>>> M2P lookup? As said, MMIO addresses shouldn't be subject to such >>>> lookups. >>> early_ioremap()-> >>> __early_ioremap()-> >>> __early_set_fixmap()-> >>> set_pte()-> >>> xen_set_pte_init()-> >>> mask_rw_pte()-> >>> pte_pfn()-> >>> pte_val()-> >>> xen_pte_val()-> >>> pte_mfn_to_pfn() >> Well, I understand (also from Boris' first reply) that's how it is, >> but not why it is so. I.e. the call flow above doesn't answer my >> question. > On x86 early_ioremap() and early_memremap() share a common sub-function > __early_ioremap(). This together with pvops requires a common set_pte() > implementation leading to the mfn validation in the end.
Do we make any assumptions about where DMI data lives? -boris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
