[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |