[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/HVM: honor p2m_ram_ro in hvm_map_guest_frame_rw()
At 07:51 -0600 on 11 Aug (1439279513), Jan Beulich wrote: > >>> On 27.07.15 at 13:09, <tim@xxxxxxx> wrote: > > At 13:02 +0100 on 24 Jul (1437742964), Andrew Cooper wrote: > >> On 24/07/15 10:41, Jan Beulich wrote: > >> > Beyond that log-dirty handling in _hvm_map_guest_frame() looks bogus > >> > too: What if a XEN_DOMCTL_SHADOW_OP_* gets issued and acted upon > >> > between the setting of the dirty flag and the actual write happening? > >> > I.e. shouldn't the flag instead be set in hvm_unmap_guest_frame()? > >> > >> It does indeed. (Ideally the dirty bit should probably be held high for > >> the duration that a mapping exists, but that is absolutely infeasible to > >> do). > > > > IMO that would not be very useful -- a well-behaved toolstack will > > have to make sure that relevant mappings are torn down before > > stop-and-copy. Forcing the dirty bit high in the meantime just makes > > every intermediate pass send a wasted copy of the page, without > > actually closing the race window if the tools are buggy. > > Making sure such mappings got torn down in time doesn't help > when the most recent write happened _after_ the most recent > clearing of the dirty flag in a pass prior to stop-and-copy. This is why e.g. __gnttab_unmap_common sets the dirty bit again as it unmaps. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |