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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: Next steps with pv_ops for Xen
From: Derek Murray <Derek.Murray@xxxxxxxxxxxx>
Date: Wed, 05 Dec 2007 18:29:07 +0000
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 10:29:53 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4756E9F2.4050502@xxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.9 (X11/20071115)
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... 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?

Regards,

Derek.

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

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