Re: [Xen-devel] [PATCH] xen/pvshim: fix GNTTABOP_query_size hypercall forwarding with SMAP

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.01.18 at 17:28, <wei.liu2@xxxxxxxxxx> wrote:
> On Fri, Jan 26, 2018 at 04:22:41PM +0000, Roger Pau Monné wrote:
>> On Fri, Jan 26, 2018 at 03:52:38PM +0000, Wei Liu wrote:
>> > On Fri, Jan 26, 2018 at 03:29:10PM +0000, Roger Pau Monne wrote:
>> > > --- a/xen/arch/x86/pv/shim.c
>> > > +++ b/xen/arch/x86/pv/shim.c
>> > > @@ -748,7 +748,10 @@ static long pv_shim_grant_table_op(unsigned int cmd,
>> > >      }
>> > >  
>> > >      case GNTTABOP_query_size:
>> > > +        /* Disable SMAP so L0 can access the buffer. */
>> > 
>> > Interesting.
>> > 
>> > > +        stac();
>> > >          rc = xen_hypercall_grant_table_op(GNTTABOP_query_size, uop.p, 
>> > > count);
>> > > +        clac();
>> > 
>> > There is so far only one instance of this, so doing this ad-hoc stac /
>> > clac is OK.
>> > 
>> > Probably another (more uniformed) way of fixing it is to have our own
>> > buffer (forbid passing through uop directly) and the copy back the
>> > result. Or we should invent a set of macros to deal with uop.
>> 
>> I guess we should figure out what's faster, disabling SMAP or copying
>> to a buffer?
>> 
> 
> It depends. If there are going to be instances that L0 needs to copy to
> a large buffer in L2 userspace, disabling SMAP is definitely better then
> bouncing.

If you wanted to uniformly copy, determining the overall size of
some of the structures would be non-trivial I think, plus you'd
run into the same space problems that makes come of the 32-bit
compat layer so ugly to read/maintain.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel