From: "Jan Beulich" <JBeulich@suse.com>
To: Juergen Gross <JGross@suse.com>
Cc: Kevin Moraga <kmoragas@riseup.net>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
xen-devel@lists.xen.org
Subject: Re: crash on boot with 4.6.1 on fedora 24
Date: Wed, 11 May 2016 00:35:11 -0600 [thread overview]
Message-ID: <5732EEBF02000078000EA613@prv-mh.provo.novell.com> (raw)
In-Reply-To: <5732C7D0.4050907@suse.com>
>>> On 11.05.16 at 07:49, <JGross@suse.com> wrote:
> On 10/05/16 18:35, Boris Ostrovsky wrote:
>> 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@suse.com> wrote:
>>>>> On 10/05/16 15:57, Jan Beulich wrote:
>>>>>>>>> On 10.05.16 at 15:39, <boris.ostrovsky@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?
>
> I don't think so.
>
> So the basic problem is the page fault due to the sparse m2p map before
> the #PF handler is registered.
>
> What do you think about registering a minimal #PF handler in
> xen_arch_setup() being capable to handle this problem? This should be
> doable without major problems. I can do a patch.
To me that would feel like working around the issue instead of
admitting that the removal of _PAGE_IOMAP was a mistake.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-05-11 6:35 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-08 22:51 crash on boot with 4.6.1 on fedora 24 Kevin Moraga
2016-05-09 7:23 ` Andrew Cooper
2016-05-09 10:05 ` Jan Beulich
2016-05-09 10:08 ` Jan Beulich
2016-05-09 14:52 ` Kevin Moraga
2016-05-09 15:53 ` Jan Beulich
2016-05-09 16:40 ` Kevin Moraga
2016-05-09 17:15 ` Boris Ostrovsky
2016-05-09 17:22 ` Kevin Moraga
2016-05-09 18:40 ` Boris Ostrovsky
2016-05-10 7:23 ` Jan Beulich
2016-05-10 13:39 ` Boris Ostrovsky
2016-05-10 13:57 ` Jan Beulich
2016-05-10 15:19 ` Juergen Gross
2016-05-10 15:35 ` Jan Beulich
[not found] ` <57321BFA02000078000EA3C2@suse.com>
2016-05-10 15:43 ` Juergen Gross
2016-05-10 16:35 ` Boris Ostrovsky
2016-05-11 5:49 ` Juergen Gross
2016-05-11 6:35 ` Jan Beulich [this message]
[not found] ` <5732EEBF02000078000EA613@suse.com>
2016-05-11 7:00 ` Juergen Gross
2016-05-11 7:15 ` Jan Beulich
[not found] ` <5732F83D02000078000EA6A2@suse.com>
2016-05-11 9:57 ` Juergen Gross
2016-05-11 10:03 ` Jan Beulich
[not found] ` <57331FA002000078000EA831@suse.com>
2016-05-11 10:10 ` Juergen Gross
2016-05-11 12:09 ` Jan Beulich
2016-05-11 10:16 ` David Vrabel
2016-05-11 12:21 ` Jan Beulich
2016-05-11 12:48 ` David Vrabel
2016-05-11 13:13 ` Jan Beulich
2016-05-11 13:15 ` Juergen Gross
2016-05-17 15:11 ` David Vrabel
2016-05-17 20:58 ` Kevin Moraga
2016-05-26 10:24 ` David Vrabel
2016-05-26 14:05 ` Boris Ostrovsky
2016-05-26 15:24 ` David Vrabel
2016-06-01 16:12 ` Martin Cerveny
2016-06-01 16:23 ` Martin Cerveny
2016-06-01 19:32 ` Boris Ostrovsky
2016-06-01 21:01 ` Martin Cerveny
2016-06-01 22:37 ` Boris Ostrovsky
2016-06-02 6:04 ` Martin Cerveny
2016-06-02 13:15 ` Martin Cerveny
2016-06-02 9:54 ` David Vrabel
2016-05-10 16:11 ` Kevin Moraga
2016-05-10 20:11 ` Boris Ostrovsky
2016-05-12 4:52 ` Kevin Moraga
-- strict thread matches above, loose matches on Subject: below --
2016-03-28 17:00 Michael Young
2016-03-29 10:07 ` Jan Beulich
2016-03-29 17:50 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5732EEBF02000078000EA613@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=JGross@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=kmoragas@riseup.net \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).