WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Question about x86/mm/gup.c's use of disabled interrupts

To: Nick Piggin <nickpiggin@xxxxxxxxxxxx>
Subject: [Xen-devel] Question about x86/mm/gup.c's use of disabled interrupts
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 18 Mar 2009 12:17:03 -0700
Cc: Linux Memory Management List <linux-mm@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Wed, 18 Mar 2009 12:17:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.19 (X11/20090105)
Hi Nick,

The comment in arch/x86/mm/gup.c:gup_get_pte() says:

        [...] What
         * we do have is the guarantee that a pte will only either go from not
         * present to present, or present to not present or both -- it will not
         * switch to a completely different present page without a TLB flush in
         * between; something that we are blocking by holding interrupts off.


Disabling the interrupt will prevent the tlb flush IPI from coming in and flushing this cpu's tlb, but I don't see how it will prevent some other cpu from actually updating the pte in the pagetable, which is what we're concerned about here. Is this the only reason to disable interrupts? Would we need to do it for the !PAE cases?

Also, assuming that disabling the interrupt is enough to get the guarantees we need here, there's a Xen problem because we don't use IPIs for cross-cpu tlb flushes (well, it happens within Xen). I'll have to think a bit about how to deal with that, but I'm thinking that we could add a per-cpu "tlb flushes blocked" flag, and maintain some kind of per-cpu deferred tlb flush count so we can get around to doing the flush eventually.

But I want to make sure I understand the exact algorithm here.

(I couldn't find an instance of a pte update going from present->present anyway; the only caller of set_pte_present is set_pte_vaddr which only operates on kernel mappings, so perhaps this is moot. Oh, look, native_set_pte_present thinks its only called on user mappings... In fact set_pte_present seems to have completely lost its rationale for existing.)

Thanks,
   J

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