Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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, <JGross@xxxxxxxx> wrote:
>>> On 10/05/16 15:57, Jan Beulich wrote:
>>>>>>> On 10.05.16 at 15:39, <boris.ostrovsky@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel