>>> On 11.05.16 at 12:10, <jgr...@suse.com> wrote:
> On 11/05/16 12:03, Jan Beulich wrote:
>>>>> On 11.05.16 at 11:57, <jgr...@suse.com> wrote:
>>> On 11/05/16 09:15, Jan Beulich wrote:
>>>>>>> On 11.05.16 at 09:00, <jgr...@suse.com> 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@lists.xen.org
http://lists.xen.org/xen-devel
