[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 09/10] log-dirty: Refine common code to support PML
At 15:38 +0800 on 10 Apr (1428680289), Kai Huang wrote: > > > On 04/09/2015 08:27 PM, Tim Deegan wrote: > > At 10:35 +0800 on 27 Mar (1427452553), Kai Huang wrote: > >> --- a/xen/arch/x86/mm/paging.c > >> +++ b/xen/arch/x86/mm/paging.c > >> @@ -411,7 +411,18 @@ static int paging_log_dirty_op(struct domain *d, > >> int i4, i3, i2; > >> > >> if ( !resuming ) > >> + { > >> domain_pause(d); > >> + > >> + /* > >> + * Only need to flush when not resuming, as domain was paused in > >> + * resuming case therefore it's not possible to have any new dirty > >> + * page. > >> + */ > >> + if ( d->arch.paging.log_dirty.flush_cached_dirty ) > >> + d->arch.paging.log_dirty.flush_cached_dirty(d); > > I think there are too many layers of indirection here. :) How about: > > - don't add a flush_cached_dirty() function to the log_dirty ops. > > - just call p2m_flush_hardware_cached_dirty(d) here. > > > > Would that work OK? > Thanks for pointing out. > > Is it nature to call p2m layer functions in paging.c? If there's no > restriction on it, calling p2m_flush_hardware_cached_dirty is more > clear, and it should work. Yes, calling public p2m functions directly is OK -- it's the internal function pointers like ->get_entry() that aren't supposed to be called from outside p2m code. I guess that's not terribly clear - maybe it needs some better comments. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |