Re: [Xen-devel] [xen-unstable test] 123379: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.06.18 at 18:19, <ian.jackson@xxxxxxxxxx> 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

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel