[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 11.05.16 at 12:10, <JGross@xxxxxxxx> wrote:
> On 11/05/16 12:03, Jan Beulich wrote:
>>>>> On 11.05.16 at 11:57, <JGross@xxxxxxxx> wrote:
>>> On 11/05/16 09:15, Jan Beulich wrote:
>>>>>>> On 11.05.16 at 09:00, <JGross@xxxxxxxx> wrote:
>>>>> Having a Xen specific pte flag seems to be much more intrusive than
>>>>> having an early boot page fault handler consisting of just one line
>>>>> being capable to mimic the default handler in just one aspect (see
>>>>> attached patch - only compile tested).
>>>> Well, this simple handler may serve the purpose here, but what's
>>>> the effect of having it in place on actual #PF (resulting e.g. from
>>>> a bug somewhere)? I.e. what diagnostic information will be
>>>> available to the developer in that case, now that the hypervisor
>>>> won't help out anymore?
>>> Good point. As fixup_exception() is returning 0 in this case we can
>>> set the #PF handler to NULL again and retry the failing instruction.
>>> This will then lead to the same hypervisor handled case as today.
>> And how would you mean to set the #PF handler to this tiny one
>> again for the next M2P access? You simply can't have both, I'm afraid.
> Why would I need another #PF handler after a crash? I meant something
> like:
> +dotraplinkage void notrace
> +xen_do_page_fault(struct pt_regs *regs, unsigned long error_code)
> +{
> +       if (!fixup_exception(regs, X86_TRAP_PF))
> +               set_intr_gate_notrace(X86_TRAP_PF, NULL);
> +}

Ah, right, that should work (albeit looks a bit, well, odd).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.