Re: [Xen-devel] Vanilla Linux and has_foreign_mapping

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

Keir Fraser wrote:
> I'm not really familiar with the pv_ops code I'm afraid. But thinking about
> this some more I've realised there's no way really to avoid making the
> early-unpin logic aware of gntdev mappings. This is because if we do pin pte
> pages, and require them to remain pinned across early-unpin, then
> pgd_unpin() must not attempt to make those pte pages writable. That will
> fail, because the pages are still pinned! You'd either need to handle the
> failure to make the page writable, or have a per-page flag to indicate which
> pte pages contain gntdev mappings. Frankly you may as well stick with the
> per-mm-context has_foreign_mappings flag.
>   
So the issue is that a pte page containing a _PAGE_IO pte must remain 
pinned while it contains that mapping?  Would shooting down the mapping 
allow it to be unpinned, or does that need to be deferred until some 
later point (if so, when?)?
I guess the downside is that we'd need to scan the pte looking for 
_PAGE_IO mappings, which is a bit of a pain.  Skipping that would mean 
hiding a flag somewhere...
> Is it a pain to add a pv_ops-subtype-specific flag to mm_context? If so you
> could maintain a set datastructure instead, indicating which mm_contexts
> contain foreign mappings.
>   
So, in 2.6.18-xen mm->has_foreign_mapping makes it skip early-unpin, but 
puts it off until pgd_free().  Presumably that works because all the 
vma's all been unmapped by then...
I wonder if Christoph/Andrea's mmu notifier patch is useful here...  Maybe?

Christoph/Andrea: would the mmu notifier mechanism allow us to 
efficiently generate the set of ptes mapping granted pages (pages from 
other domains), so we can shoot them down during process exit?
   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel