Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754132AbYAWMwb (ORCPT ); Wed, 23 Jan 2008 07:52:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753909AbYAWMwW (ORCPT ); Wed, 23 Jan 2008 07:52:22 -0500 Received: from mx1.redhat.com ([66.187.233.31]:49034 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753887AbYAWMwV (ORCPT ); Wed, 23 Jan 2008 07:52:21 -0500 Message-ID: <4797384B.7080200@redhat.com> Date: Wed, 23 Jan 2008 13:51:23 +0100 From: Gerd Hoffmann User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Christoph Lameter CC: Andrea Arcangeli , Andrew Morton , Nick Piggin , linux-mm@kvack.org, Benjamin Herrenschmidt , steiner@sgi.com, linux-kernel@vger.kernel.org, Avi Kivity , kvm-devel@lists.sourceforge.net, daniel.blueman@quadrics.com, holt@sgi.com, Hugh Dickins Subject: Re: [kvm-devel] [PATCH] export notifier #1 References: <20080113162418.GE8736@v2.random> <20080116124256.44033d48@bree.surriel.com> <478E4356.7030303@qumranet.com> <20080117162302.GI7170@v2.random> <478F9C9C.7070500@qumranet.com> <20080117193252.GC24131@v2.random> <20080121125204.GJ6970@v2.random> <4795F9D2.1050503@qumranet.com> <20080122144332.GE7331@v2.random> <20080122200858.GB15848@v2.random> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1626 Lines: 40 Hi, Jumping in here, looks like this could develop into a direction useful for Xen. Background: Xen has a mechanism called "grant tables" for page sharing. Guest #1 can issue a "grant" for another guest #2, which in turn then can use that grant to map the page owned by guest #1 into its address space. This is used by the virtual network/disk drivers, i.e. typically Domain-0 (which has access to the real hardware) maps pages of other guests to fill in disk/network data. Establishing and tearing down mappings for those grants must happen through a special grant table hypercall, and especially for the tear down part of the problem mmu/export/whatever-we-call-them-in-the-end notifies could help. > Issues with mmu_ops #2 > > - Notifiers are called *after* we tore down ptes. That would render the notifies useless for Xen too. Xen needs to intercept the actual pte clear and instead of just zapping it use the hypercall to do the unmap and release the grant. Current implementation uses a new vm_ops operation which is called if present instead of doing a ptep_get_and_clear_full(). It is in the XenSource tree only, mainline hasn't this yet due to implementing only the DomU bits so far. When adding Dom0 support to mainline we'll need some way to handle it, and I'd like to see the notifies be designed in a way that Xen can simply use them. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/