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

Re: [Xen-devel] [PATCH v3 2/3] xen: implement guest_physmap_(un)pin_range



On Wed, 2013-08-14 at 17:08 +0100, Stefano Stabellini wrote:
> On Thu, 8 Aug 2013, Ian Campbell wrote:

> > > +        if ( !third ||
> > > +                !third[third_table_offset(addr)].p2m.valid ||
> > > +                third[third_table_offset(addr)].p2m.avail & P2M_DMA_PIN )
> > 
> > At this point rc == -EFAULT, which doesn't seem right when failing the
> > P2M_DMA_PIN check.
> 
> I'll go with -EINVAL. Do you have any better suggestions otherwise?

-EBUSY sort of fits here I guess?

> > > +        if ( third[third_table_offset(addr)].p2m.avail & P2M_DMA_PIN )
> > > +        {
> > > +            rc = -EINVAL;
> > > +            printk("%s: cannot change p2m mapping for paddr=%"PRIpaddr
> > > +                    " domid=%d, the page is pinned\n", __func__, addr, 
> > > d->domain_id);
> > 
> > Not sure if a guest can trigger this, if yes then gdprintk.
> > 
> > Do we always clear this bit when we clear the present bit? If not then
> > we could end up with entries which are pinned and not-present. We should
> > probably avoid that one way or another!
> 
> I went through the code: yes we do, because we always reset the entire
> pte entry rather than only the valid bit.

Good!

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®.