[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen: xen_sync_dirty_bitmap: attempt to fix SEGV



Alex Bligh writes ("Re: [PATCH] xen: xen_sync_dirty_bitmap: attempt to fix 
SEGV"):
> Thanks. So the good news is that it is xen_sync_dirty_bitmap that is
> the culprit, as we suspected.
> 
> My question is: does the call to cpu_physical_memory_set_dirty
> occur within the "if (rc<0)" block, as I suspect, or does it occur
> within the "for (i = 0; i < ARRAY_SIZE(bitmap); i++)" block?
> (it's called in two places from xen_sync_dirty_bitmap)

Line 481, see below.  (You should be able to see that from the stack
trace I sent, which was generated from the tip of
qemu-upstream-4.2-testing.git, eccc68722696864fc4823f048c7be58d11281b97)

> If the former, then I think the problem is that the address that
> cpu_physical_memory_set_dirty (and xen_modified_memory) takes needs
> to be passed through get_physmapping()->phys_offset before use,
> like the second case already does. In this case the patch I've
> just sent should (hopefully) work.

   479              end = TARGET_PAGE_ALIGN(start_addr + size);
   480              for (addr = start_addr & TARGET_PAGE_MASK; addr < end; addr 
+= TARGET_PAGE_SIZE) {
   481                  cpu_physical_memory_set_dirty(addr);
   482              }
   483  
   484              DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx

I shall try your patch.

Ian.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.