From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: pv_ops & gntdev? Date: Wed, 25 Feb 2009 14:28:11 -0800 Message-ID: <49A5C5FB.6080000@goop.org> References: <49A44030.2070709@redhat.com> <49A4640E.1000807@goop.org> <49A470DD.2000008@redhat.com> <49A517F6.30005@redhat.com> <49A58506.2020407@goop.org> <49A58FFF.3050604@redhat.com> <49A5A4BD.7080207@goop.org> <49A5B5DD.60309@redhat.com> <49A5B9AA.7010709@goop.org> <49A5BB7E.8030503@redhat.com> <49A5BC9D.5010801@goop.org> <49A5C208.2040509@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49A5C208.2040509@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gerd Hoffmann Cc: Xen Development Mailing List List-Id: xen-devel@lists.xenproject.org Gerd Hoffmann wrote: > Unmapping the grants when the kernel is about to zap the page range. > I think it could be easier because I don't have to link the low-level > paravirt code with the gntdev driver then. Also I can easily batch > unmaps. And there is a performance hit for the extra checks only for > processes which actually use grants. > Would the unmap operation on the vma be enough to do that? Hm, I guess vm_operations_struct needs something that gets called before the zap rather than after (->close). > The (unclean) exit case might be tricky though. Could be the kernel > tries to unpin before zapping all mappings, so we don't trap into xen > all the time. > Yes, the unpin needs to make sure it clears out all the grant refs, because you just can't unpin otherwise. The alternative is to hook into the fault handler so that a fault-n-emulate operation on the pagetable which fails because of the grant reference can be fixed up at that point. But that might be even more intrusive. J