18 messages in com.xensource.lists.xen-develRe: [Xen-devel] Vanilla Linux and has...
FromSent OnAttachments
Michael Abd-El-Malek20 Apr 2008 14:18 
Jeremy Fitzhardinge21 Apr 2008 04:46 
Mark McLoughlin21 Apr 2008 09:36.patch
Keir Fraser21 Apr 2008 10:52 
Michael Abd-El-Malek21 Apr 2008 10:59 
Michael Abd-El-Malek21 Apr 2008 11:10 
Michael Abd-El-Malek21 Apr 2008 11:16 
Keir Fraser21 Apr 2008 11:29 
Jeremy Fitzhardinge24 Apr 2008 17:17 
Keir Fraser24 Apr 2008 23:01 
Michael Abd-El-Malek25 Apr 2008 10:11 
Jeremy Fitzhardinge25 Apr 2008 11:21 
Michael Abd-El-Malek25 Apr 2008 11:30 
Jeremy Fitzhardinge25 Apr 2008 15:33 
Jeremy Fitzhardinge25 Apr 2008 17:13 
Michael Abd-El-Malek29 Apr 2008 09:39 
Jeremy Fitzhardinge29 Apr 2008 10:31 
Michael Abd-El-Malek30 Apr 2008 09:30 
Subject:Re: [Xen-devel] Vanilla Linux and has_foreign_mapping
From:Keir Fraser (keir@eu.citrix.com)
Date:04/24/2008 11:01:16 PM
List:com.xensource.lists.xen-devel

On 25/4/08 01:18, "Jeremy Fitzhardinge" <jer@goop.org> wrote:

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?)?

If you have _PAGE_IO then only unpinning of ptes containing grant-table mappings must not be deferred. 'Ordinary' foreign mappings, of the sort that dom0 can create because it is privileged, do not have this constraint. This is because you can tell they are foreign, and hence avoid page refcounting, simply because the pte contains _PAGE_IO. Without _PAGE_IO we relied on checking whether a machine->pseudophys->machine double lookup took us from the machine address in the pte back to the same machine address. If not, we knew the page was not ours. This doesn't work reliably if the pte page is not pinned because in that case the mapped page can be freed from the foreign domain and be reallocated into the local domain: in which case the M->P->M check could succeed! The _PAGE_IO check is more robust.

-- Keir