[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Grant tables from dom0 userspace?

  • To: "King, Steven R" <steven.r.king@xxxxxxxxx>
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

> 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. ;)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.