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

Re: [Xen-devel] Sources of page dirtying for HVM domains in Xen 3.2.x



Hi, 

At 06:06 -0700 on 03 Oct (1223013977), Mike Sun wrote:
> One confusing thing is that it seems that since _sh_propagate() is
> called before the emulated write or MMIO write that the page_dirty()
> would already be called and that the page_dirty() called after the
> emulated write is redundant?  I'm probably missing something though.

For emulated writes to pagetables, the _sh_propagate() call doesn't make
a writeable mapping (since the target is a pagetable) so it shouldn't
call page_dirty().

> Any way I can have Qemu not do DMA?

Don't use disks or network cards? :)  It should be possible to set the
IDE controller up to do PIO, but presumably your performance would then
suck.

> Essentially I'm looking for a clean way of doing a copy-on-write on a
> guest domain's memory pages.  The log-dirty mode seems most
> appropriate, but I have to make sure I can copy the page before it's
> dirtied/modified.  Have any good suggestions.

The log-dirty mode seems like a good candidate, but there are a
number of places where log-dirty marks a page dirty _after_ writing to
it; in particular qemu DMA.  It might be possible to reshuffle so that
that the marking happens before the write in all cases, but it needs
some thought about race conditions like:
 1. mark dirty
 2. live-migration tool copies the page and clears the bitmap
 3. write to the page
I suspect you end up having to take action both before and after some
writes (ones that happen inside Xen are OK because the domain is always
paused when the bitmap is read so as long as you finish the writes
before returning from Xen you're safe).

Another option is to hook everything from the p2m table lookup
operation, though you'd then need to plumb through a "read/write"
argument to lookups so you don't trigger on reads too.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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