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] Grant tables from dom0 userspace?

To: "King, Steven R" <steven.r.king@xxxxxxxxx>
Subject: Re: [Xen-devel] Grant tables from dom0 userspace?
From: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
Date: Fri, 10 Mar 2006 11:14:16 -0800
Cc: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Jacob Gorm Hansen <jacobg@xxxxxxx>, xen-devel Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 10 Mar 2006 19:15:09 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MiTKn6q1kFdO5+Zj3sf2H48MCsjJDMp79T1dmMC9SrFhRIJXtiNmsuMPjs3r6hJ4kK2qQxCDob6ley4uYXs2FLl0jbe1oeyEqmy/07Mp0rl8i0TLm+qLJHbZBu3g4a9baQ3XunM8RPWVoy9Moo6RdVQGpsripsbc+9Wga6zVw9s=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <44BDAFB888F59F408FAE3CC35AB4704103328A57@orsmsx409>
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: <44BDAFB888F59F408FAE3CC35AB4704103328A57@orsmsx409>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> At this point, the Linux has just squashed the pte.  Xen code knows the
> l1e, and I've added a few more bits to the maptrack object to allow me
> to find a match from the corresponding pfn.  It's kludgey, because this
> only works in the special case where only one map track entity exists
> for a given pfn per domain.  This is problem #1.  Ideas?  If we had the
> exact address of the pte, there would be no ambiguity in which maptrack
> entry owns the mapping.  I nosed around and did not find a way to get
> the pte addr, but still hold out hope that it's possible.
>
> Armed with the "correct" maptrack entry, I can do most of the ummapping
> work then and there.  Later, I get the "late" vma_close() from the OS
> where my guest driver explicitly unmaps to finish the job.

If you are going down the implicit unmap path, I don't think that
trying to sleuth out the PTE after the fact and based on partial
information is the right way to go.  I'd think it would make more
sense to store the PTE that the grant has been bound to explicity and
hook the implicit unmap off of the pte update validation code in Xen. 
I'd be interested to hear what keir thinks though...  iirc, the
original concern with this sort of approach was the space overhead of
storing all the outstanding mapping -- the maptracks are intentionally
very lightweight.

> All is well, and I'm back at the guest command prompt.  Problem #2 is
> that the balloon driver crashes me if I try to restart my user-level
> app.  The dump looks like this:

I don't see a BUG() at line 218 of my version of balloon.c, but
presumably you are failing one of the sanity checks in
increase_reservation.  Sounds like there may be a bug hunting trip in
your future. ;)

a.

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

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