Re: [Xen-devel] [PATCH RFC 1/4] x86/mm: Shadow and p2m changes for PV mem_access

[Tim Deegan <tim@xxxxxxx>]

At 19:14 +0000 on 01 May (1398968076), Aravindh Puthiyaparambil (aravindp) 
wrote:
> >> (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
> >> mfn 33960: c=8000000000000002 t=7400000000000000 <most common>
> >>  (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
> >> mfn 134b8: c=8000000000000038 t=7400000000000001
> >
> >This is because you are not in shadow_mode_refcounts() (i.e. the page's
> >refcount and typecount are based on the _guest_ pagetables rather than the
> >_shadow_ ones).  That means that sh_remove_all_mappings() can't use the
> >refcounts to figure out when it's removed the last shadow mapping.
> 
> I take it that I won't be able to run with shadow_mode_refcounts() for PV 
> domains.

Nope, that's not an option. :(  The PV MM code uses typecounts in
various places that aren't visible from just the pagetables, so we
can't let the shadow pagetable code control them.

> >That also means that sh_remove_all_mappings() will have had to search every
> >sl1e in the system, which is expensive.  If there will be a lot of these 
> >updates,
> >you might consider batching them and using
> >shadow_blow_tables() after each batch instead.
> 
> Does this mean batching them in the hypervisor or in the mem_access
> listener?

Either, I suppose.

> Typically one would want the effect of the new permissions
> to kick in immediately. So I am afraid batching them will delay
> this. Anyhow, at a minimum I will add a comment here as to why I am
> adding the check here. Once the feature has gone in I will revisit
> to see if I can add some performance improvements in this area.

Righto.  

Tim.

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