[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/3] xen: introduce XENMEM_get_dma_buf and XENMEM_put_dma_buf
On Tue, 2013-08-13 at 17:05 +0100, Stefano Stabellini wrote: > On Thu, 8 Aug 2013, Ian Campbell wrote: > > > The new pages are going to be "pinned": it's guaranteed > > > + * that their p2m mapping won't be changed until explicitly "unpinned". > > > > We have a privilege level check here through the use of > > multipage_allocation_permitted, which permits up to 2MB mappings. But > > unlike the original exchange these can be cumulative. Do we need a per > > domain limit on the number of pinned p2m pages? My gut feeling is yes, > > otherwise a guest can pin 1 page in every 2MB range, which isn't so bad > > now but will cause fragementation issues when we switch to 2MB p2m > > mappings. > > Wouldn't it cause fragementation issues only to itself? What I meant is that if a guest pins one page out of the 512 in a 2MB mapping then the other 511 pages can't easily/efficiently be used for other guests even though they are "free". I don't know if it would be unreasonable to account the full 2MB range to the guest until it has free'd it all, perhaps with some sort of per-domain "free" list so that the guest can cause itself pain by reusing them. Needs some thought... > As far as I can tell the only problem that pinned p2m pages can cause to > the hypervisor is preventing Xen from swapping or sharing domain pages. You are right about swapping, but pinning would necessarily imply an unshare I think. Is there any point in a r/o pin? I suspect not. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |