>>> On 30.11.17 at 10:10, <jbeul...@suse.com> wrote: > Olaf has observed this assertion to trigger after an aborted migration > of a PV guest (it remains to be determined why there is a page fault in > the first place here: > > (XEN) Xen call trace: > (XEN) [<ffff82d0802a85dc>] do_page_fault+0x39f/0x55c > (XEN) [<ffff82d08036b7d8>] x86_64/entry.S#handle_exception_saved+0x66/0xa4 > (XEN) [<ffff82d0802a9274>] __copy_to_user_ll+0x22/0x30 > (XEN) [<ffff82d0802772d4>] update_runstate_area+0x19c/0x228 > (XEN) [<ffff82d080277371>] domain.c#_update_runstate_area+0x11/0x39 > (XEN) [<ffff82d080277596>] context_switch+0x1fd/0xf25 > (XEN) [<ffff82d0802395c5>] schedule.c#schedule+0x303/0x6a8 > (XEN) [<ffff82d08023d067>] softirq.c#__do_softirq+0x6c/0x95 > (XEN) [<ffff82d08023d0da>] do_softirq+0x13/0x15 > (XEN) [<ffff82d08036b2f1>] x86_64/entry.S#process_softirqs+0x21/0x30 > > i.e. the guest specified a runstate area address which has a non-present > mapping in the page tables [EC=0002 CR2=ffff88003d405220], but that's > not something the hypervisor needs to be concerned about.)
It occurred to me only after sending that this would legitimately happen when the vCPU is in user mode, i.e. likely nothing to be concerned about. I guess I'll drop this part of the description. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
