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: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Wed, 12 Dec 2007 17:27:27 +0900
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Eduardo Habkost <ehabkost@xxxxxxxxxx>, Juan Quintela <quintela@xxxxxxxxxx>, "Stephen C. Tweedie" <sct@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, "virtualization@xxxxxxxxxxxxxx" <virtualization@xxxxxxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 12 Dec 2007 00:28:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4756EAD5.9050407@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Wed, Dec 05, 2007 at 06:15:49PM +0000, Derek Murray wrote:
> Keir Fraser wrote:
> >Yes, this would work okay I suspect. Good enough as a stop-gap measure? Are
> >there any other responsibilities that you acquire if you make use of
> >VM_FOREIGN (in particular, how would this affect get_user_pages)?
> 
> VM_FOREIGN is already set for the gntdev VMA (mostly because it's 
> directly based on the blktap code). That means that it has the array of 
> page_structs in its vm_private_data, which can be used to fulfill a 
> get_user_pages call. I've attached a patch based on this fix.
> 
> Regards,
> 
> Derek.

Hi Derek. Sorry for this late alert.

This patch breaks blktap and gntdev on ia64.
With auto translated physmap mode enabled, bktap/gntdev update
the pte entry with vm_insert_page(). Not direct updating it with
the hypercall.
So when zapping the pte entry, it is necessary to release page
reference counting, rmapping and etc. Thus vm_normal_page() have
to return the struct page when auto translated physmap mode is enabled.

How about passing the page struct** to the zap_pte call back
and set it to NULL if necessary?
(or
Can the condition be changed to check auto trasnalted physmap mode?
or
Should the clean up be done in zap_pte callback?)
-- 
yamahata

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

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