[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Grant tables from dom0 userspace?
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |