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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel