All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Bligh <alex@alex.org.uk>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Alex Bligh <alex@alex.org.uk>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [qemu-upstream-4.2-testing test] 16779: regressions - FAIL
Date: Mon, 04 Mar 2013 15:08:05 +0000	[thread overview]
Message-ID: <FFEC93DCF8EFD81B516DDB53@Ximines.local> (raw)
In-Reply-To: <alpine.DEB.2.02.1303022248420.22839@kaball.uk.xensource.com>

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.

My problem is trying to replicate 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:

Me too. This was the bit that I couldn't actually work out what it was 
doing and why.

In the original patch (below) it called memory_region_set_dirty, which
doesn't exist in 4.2, with the parameter 'framebuffer', which also doesn't
exist in 4.2. This only gets called if xc_hvm_track_dirty_vram returns
an error other than ENODATA. I had presumed the intent was to mark the
whole framebuffer as dirty if xc_hvm_track_dirty_vram failed this way.

Does the loop start (and end) need to start from vram_offset (i.e.
physmap->phys_offset), rather than start_addr? I suspect my confusion
is that both start_addr and vram_offset are target_phys_addr_t but
one is one side of a mapping and one the other.

>
> @@ -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
>
>


Original patch:

diff --git a/xen-all.c b/xen-all.c
index b11542c..e6308be 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
                                  bitmap);
     if (rc < 0) {
         if (rc != -ENODATA) {
-            fprintf(stderr, "xen: track_dirty_vram failed (0x" 
TARGET_FMT_plx
+            memory_region_set_dirty(framebuffer, 0, size);
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
                     ", 0x" TARGET_FMT_plx "): %s\n",
                     start_addr, start_addr + size, strerror(-rc));
         }


-- 
Alex Bligh

  parent reply	other threads:[~2013-03-04 15:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01 14:07 [qemu-upstream-4.2-testing test] 16779: regressions - FAIL xen.org
2013-03-01 16:15 ` Ian Jackson
2013-03-01 21:18   ` Alex Bligh
2013-03-03  1:57     ` Stefano Stabellini
2013-03-04 11:40       ` Ian Jackson
2013-03-04 15:14         ` Alex Bligh
2013-03-05 17:10           ` Ian Jackson
2013-03-06 14:15             ` Alex Bligh
2013-03-06 14:10           ` [PATCH] xen: xen_sync_dirty_bitmap: attempt to fix SEGV Alex Bligh
2013-03-06 14:16             ` Ian Jackson
2013-03-06 14:35               ` Alex Bligh
2013-03-06 14:45                 ` Ian Jackson
     [not found]                 ` <1362581885-13221-1-git-send-email-alex@alex.org.uk>
2013-03-06 17:12                   ` [PATCH] xen: xen_sync_dirty_bitmap: attempt to fix SEGV [and 1 more messages] Ian Jackson
2013-03-06 18:15                     ` Alex Bligh
2013-03-07 10:57                       ` Ian Jackson
2013-03-04 15:08       ` Alex Bligh [this message]
2013-03-06 14:14         ` [qemu-upstream-4.2-testing test] 16779: regressions - FAIL Ian Jackson
2013-03-04 11:38     ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FFEC93DCF8EFD81B516DDB53@Ximines.local \
    --to=alex@alex.org.uk \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=anthony.perard@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.