[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 19:14 +0000 on 01 May (1398968076), Aravindh Puthiyaparambil (aravindp) 
> >> (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.



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.