From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH v5 3/4] xen: implement
 guest_physmap_pin_range and guest_physmap_unpin_range
Date: Fri, 27 Sep 2013 16:27:52 +0100
Message-ID: <1380295672.13347.21.camel@kazak.uk.xensource.com>
References: <alpine.DEB.2.02.1309091701140.6397@kaball.uk.xensource.com>
	<1378742763-24299-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1378805635.21748.55.camel@kazak.uk.xensource.com>
	<alpine.DEB.2.02.1309271616330.5498@kaball.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <alpine.DEB.2.02.1309271616330.5498@kaball.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, tim@xen.org
List-Id: xen-devel@lists.xenproject.org

On Fri, 2013-09-27 at 16:23 +0100, Stefano Stabellini wrote:
> On Tue, 10 Sep 2013, Ian Campbell wrote:
> > On Mon, 2013-09-09 at 17:06 +0100, Stefano Stabellini wrote:
> > >  
> > > +static int pin_one_pte(lpae_t *ptep, void *arg, int level)
> > > +{
> > > +    lpae_t pte = *ptep;
> > > +    ASSERT(level == 3);
> > > +
> > > +    if ( pte.p2m.avail & P2M_DMA_PIN )
> > > +        return -EBUSY;
> > > +    pte.p2m.avail |= P2M_DMA_PIN;
> > > +    write_pte(ptep, pte);
> > > +    return 0;
> > > +}
> > > +
> > > +int guest_physmap_pin_range(struct domain *d,
> > > +                            xen_pfn_t gpfn,
> > > +                            unsigned int order)
> > > +{
> > > +    return p2m_walker(d, gpfn << PAGE_SHIFT, order,
> > > +                      pin_one_pte, NULL);
> > 
> > Did we not also discuss accounting and limits on the amount of memory a
> > guest can lock down?
>  
> I am thinking to allow hardware domains (is_hardware_domain(d)) to pin
> any number of pages, while preveting any other domains from doing it.

That would work.

FWIW XENMEM_exchange uses multipage_allocation_permitted which allows
any guest to allocate 2MB contiguous chunks and domains with a rangeset
(i.e. dom0 or passthrough) to allocate whichever chunk they want (or at
least lets them try).

I'm not sure that pinning and exchanging are analogous though, you
blanket privileged only rule will suffice until we implement
passthrough.

Ian.