On 06/06/18 11:35, Jan Beulich wrote:
>>>> On 05.06.18 at 18:19, <ian.jack...@citrix.com> wrote:
>>>> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2
>>
>> I thought I would reply again with the key point from my earlier mail
>> highlighted, and go a bit further. The first thing to go wrong in
>> this was:
>>
>> 2018-05-30 22:12:49.320+0000: xc: Failed to get types for pfn batch (14 =
>> Bad address): Internal error
>> 2018-05-30 22:12:49.483+0000: xc: Save failed (14 = Bad address): Internal
>> error
>> 2018-05-30 22:12:49.648+0000: libxl-save-helper: complete r=-1: Bad address
>>
>> You can see similar messages in the other logfile:
>>
>> 2018-05-30 22:12:49.650+0000: libxl:
>> libxl_stream_write.c:350:libxl__xc_domain_save_done: Domain 3:saving domain:
>> domain responded to suspend request: Bad address
>>
>> All of these are reports of the same thing: xc_get_pfn_type_batch at
>> xc_sr_save.c:133 failed with EFAULT. I'm afraid I don't know why.
>>
>> There is no corresponding message in the host's serial log nor the
>> dom0 kernel log.
>
> I vaguely recall from the time when I had looked at the similar Windows
> migration issues that the guest is already in the process of being cleaned
> up when these occur. Commit 2dbe9c3cd2 ("x86/mm: silence a pointless
> warning") intentionally suppressed a log message here, and the
> immediately following debugging code (933f966bcd x86/mm: add
> temporary debugging code to get_page_from_gfn_p2m()) was reverted
> a little over a month later. This wasn't as a follow-up to another patch
> (fix), but following the discussion rooted at
> https://lists.xenproject.org/archives/html/xen-devel/2017-06/msg00324.html
That was -ESRCH, not -EFAULT.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
