Re: [Xen-devel] [qemu-upstream-4.2-testing test] 16779: regressions - FAIL

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 1 Mar 2013, Alex Bligh wrote:
> Ian, Stefano,
> 
> --On 1 March 2013 16:15:16 +0000 Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> 
> wrote:
> 
> > Looking at the changes, it seems likely to be related to the migration
> > dirty bit tracking series.  These were originally written by Anthony
> > Perard and committed to qemu-upstream-unstable where they work, and
> > then backported by Alex Blight.
> >
> > So the problem is probably something in Alex's backports ?
> 
> Do we know from the test thing that it's definitely the last patch
> in the series (i.e. the specific one indicated)? That last patch is
> the only one with substantive modifications to it, and I wasn't
> entirely clear what the original code did (as posted here).
> 
> Also do we know how to trigger/replicate this (I'm afraid I don't
> know how to read the output).

I think it's just a standard Windows XP SP3 install in a VM


> > We want to be able to release Xen 4.2 soon.  Our next step is probably
> > to revert the migration changes so that we have a tree which works as
> > well as it did before.
> 
> Stefano had an alternate way of fixing this though it involved un-inlining
> something IIRC. Perhaps I should go back and look at that.
> 
> Any ideas Stefano?

It could be any of the last 6 commits: I would start by bisecting the
problem further until you manage to pinpoint the precise backport that
caused it. But like you say, it is probably the last one.
Consider that the changes introduced by the last commit are only useful
for live-migration, you can try to remove one by one to figure out
exactly what's breaking Windows install.
My guess would be this chunk:


@@ -470,7 +470,21 @@ static int xen_sync_dirty_bitmap(XenIOState *state,
     rc = xc_hvm_track_dirty_vram(xen_xc, xen_domid,
                                  start_addr >> TARGET_PAGE_BITS, npages,
                                  bitmap);
-    if (rc) {
+    if (rc < 0) {
+        if (rc != -ENODATA) {
+            ram_addr_t addr, end;
+
+            xen_modified_memory(start_addr, size);
+            
+            end = TARGET_PAGE_ALIGN(start_addr + size);
+            for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr += 
TARGET_PAGE_SIZE) {
+                cpu_physical_memory_set_dirty(addr);
+            }
+
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+                    ", 0x" TARGET_FMT_plx "): %s\n",
+                    start_addr, start_addr + size, strerror(-rc));
+        }
         return rc;
     }
 
in particular the loop around cpu_physical_memory_set_dirty

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