Re: [Xen-devel] [PATCH v12] introduce XENMEM_reserved_device_memory_map

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2015/7/22 21:03, Jan Beulich wrote:
> > > > On 22.07.15 at 14:55, <tiejun.chen@xxxxxxxxx> wrote:
> > >   +#ifdef HAS_PASSTHROUGH
> > > +        case XENMEM_reserved_device_memory_map:
> > > +        {
> > > +            struct get_reserved_device_memory grdm;
> > > +
> > > +            if ( unlikely(start_extent) )
> > > +                return -ENOSYS;
> > > +
> > > +            if ( copy_from_guest(&grdm.map, compat, 1) ||
> > > +                 !compat_handle_okay(grdm.map.buffer, grdm.map.nr_entries)
> > )
> > > +                return -EFAULT;
> > > +
> > > +            if ( grdm.map.flags & ~XENMEM_RDM_ALL )
> > > +                return -EINVAL;
> > > +
> > > +            grdm.used_entries = 0;
> > > +            rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
> > > +                                                  &grdm);
> > > +
> > Just as you asked me previously,
> >
> > Here if RDM doesn't exist, so
> >
> > grdm.map.nr_entries = grdm.used_entries = 0, and rc = 0, right?
> No, grdm.map.nr_entries still holds whatever the caller passed.
What if the caller pass "0" like raising an inquiry? Indeed, this is 
what we did in patch #11. I think this is reasonable since the caller 
always doesn't know how much buffers should be allocated beforehand, so 
instead, the caller prefer to make this sort of inquiry without any 
buffers.
> > > +            if ( !rc && grdm.map.nr_entries < grdm.used_entries )
> > > +                rc = -ENOBUFS;
> > > +            grdm.map.nr_entries = grdm.used_entries;
> > > +            if ( __copy_to_guest(compat, &grdm.map, 1) )
> > So can we still do this copy here?
> We not only can, we need to. The only case where we might skip it
> is when the incoming grdm.map.nr_entries is unchanged.
If what I'm saying above is right, __copy_to_guest() would return a 
error in this case, right? I don't think this make sense.
Thanks
Tiejun

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel