Re: [Xen-devel] [PATCH v2 1/6] x86/EPT: don't walk entire page tables when globally changing types

[Tim Deegan <tim@xxxxxxx>]

At 17:20 +0100 on 24 Apr (1398356409), Jan Beulich wrote:
> >>> On 24.04.14 at 17:41, <tim@xxxxxxx> wrote:
> > At 13:28 +0100 on 22 Apr (1398169701), Jan Beulich wrote:
> >> --- a/xen/arch/x86/mm/hap/hap.c
> >> +++ b/xen/arch/x86/mm/hap/hap.c
> >> @@ -110,11 +110,18 @@ int hap_track_dirty_vram(struct domain *
> >>          if ( begin_pfn != dirty_vram->begin_pfn ||
> >>               begin_pfn + nr != dirty_vram->end_pfn )
> >>          {
> >> +            unsigned long ostart = dirty_vram->begin_pfn;
> >> +            unsigned long oend = dirty_vram->end_pfn;
> >> +
> >>              dirty_vram->begin_pfn = begin_pfn;
> >>              dirty_vram->end_pfn = begin_pfn + nr;
> >>  
> >>              paging_unlock(d);
> >>  
> >> +            if ( oend > ostart )
> >> +                p2m_change_type_range(d, ostart, oend,
> >> +                                      p2m_ram_logdirty, p2m_ram_rw);
> >> +
> > 
> > Does this (and the simlar change below) not risk losing updates if
> > we're in full log-dirty mode?  I think it should be fine to leave
> > those entries as log-dirty, since at worst they'll provoke another
> > fault-and-fixup.
> 
> I don't think any updates can be lost: When their types get re-
> calculated, p2m_is_logdirty_range() (taking p2m->global_logdirty
> into account) will still cause them to become p2m_ram_logdirty
> again.

Right, I see.  That's fine then.

> > In this case, where needs_sync isn't being passed as a return value, I
> > think we'd be fine with two booleans in place of this int.
> 
> I guess I'll make these tristates distinct enums then...

Thanks!

Tim.

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