[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


 


Rackspace

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