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

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

To: Derek Murray <Derek.Murray@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Next steps with pv_ops for Xen
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 05 Dec 2007 12:15:01 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Eduardo Habkost <ehabkost@xxxxxxxxxx>, Juan Quintela <quintela@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, "virtualization@xxxxxxxxxxxxxx" <virtualization@xxxxxxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxxxxx>
Delivery-date: Wed, 05 Dec 2007 12:15:40 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4756EDF3.30501@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1195682725.6726.48.camel@xxxxxxxxxxxxxxxxxxxxx> <4753FC6A.4020601@xxxxxxxxxx> <4754024C.7020905@xxxxxxxxxxxx> <47540FB8.8000106@xxxxxxxxxx> <475417E7.9070006@xxxxxxxxxxxx> <47546931.2090602@xxxxxxxxxx> <475520A1.6080909@xxxxxxxxxxxx> <475541A8.7030100@xxxxxxxxxx> <1196771999.10809.18.camel@xxxxxxxxxxxxxxxxxxxxx> <4755B158.3030008@xxxxxxxxxx> <47569014.8080008@xxxxxxxxxxxx> <4756E9F2.4050502@xxxxxxxx> <4756EDF3.30501@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.9 (X11/20071115)
Derek Murray wrote:
> Jeremy Fitzhardinge wrote:
>> Could we use one of the software-defined bits in the PTE to indicate
>> that this is a foreign/granted PTE, and have set_pte_at behave
>> differently if you pass it a pte with this bit set?
>
> Actually, as Gerd pointed out in his answer to his own question, the
> use of VM_DONTCOPY cuts out this entire code path, so we don't need to
> worry about it.
>
> Mind you, it looks like we're going to go ahead and use one of the PTE
> bits to signify foreign PTEs anyway, per Keir's suggestion. Either
> way, it's going to involve making Xen-specific changes to the mm code... 

Sneaking in a user for the otherwise completely unused PTE bits should
be fairly straightforward.

> have you any ideas how we can either (i) get rid of the zap_pte hook
> in the vm_operations_struct, or (ii) make a really compelling case to
> the kernel maintainers that it really should get in? 

Hm, I haven't spent much time looking at how grant tables and their
mappings work yet, so I can't say I really understand all this myself. 
Hence, questions:

Can we take a different approach from the zap_pte hook?  Given that
we're 1) planning on claiming a pte bit for grant mappings, and 2) need
to hook ptep_get_and_clear anyway to solve the mprotect performance
problems, couldn't we just special-case grant mapping pte_clears?

In 2.6.18-xen the only two implementations of zap_pte are
blktap_clear_pte and gntdev_clear_pte.  Given a ptep with the
grant-mapping bit set, could we determine which of these need calling
and do the appropriate thing?  Do we even need separate implementations
of the core pte-clearing functionality?  Could we just say something like:

        if (pte & _PAGE_XEN_FOREIGN)
                HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, ...);
        else
                xen_set_pte_at(...);


blktap_clear_pte and gntdev_clear_pte do other housekeeping, but do they
have to be done at the same instant as the grant mapping clear?  Could
they be done via some other hook?

(I see Gerd just proposed this, pretty much.)

    J

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

<Prev in Thread] Current Thread [Next in Thread>