|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
xen-devel
RE: [Xen-devel] pointers in hcalls
 
 >  
> Message: 1 
> Date: Tue, 07 Feb 2006 13:58:05 +1100 
> From: Hollis Blanchard <hollisb@xxxxxxxxxx> 
> Subject: [Xen-devel] pointers in hcalls 
> To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 
> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx> 
> Message-ID: <1139281085.13776.29.camel@xxxxxxxxxxxxxxxxxxxxx> 
> Content-Type: text/plain 
>  
> This is a followup to our conversation at the Xen summit about userspace 
> passing virtual addresses to the hypervisor. 
>  
> We talked about an API where data structures would be allocated from
a 
> special area of memory. This API became rather hairy, which we can
talk 
> about. However, it seems to me that the simplest way to handle this
is 
> to disallow pointers entirely, instead embedding the structures in
the 
> higher-level structure. I've had a look through this, and I actually 
> don't think that would be too bad. 
>  
> When performing this conversion, we could initially exempt the 
> arch-specific hcalls. For consistency I think we'd want to do them
all, 
> but that's not necessary for correctness. Also, constraining these 
> expanded structures to a single page would be best. 
>  
> So I had a look through most (all?) of the hcalls in 
> xen/include/public/*.h to see which would pose problems. I don't see
any 
> show-stoppers: 
> - some hcalls, such as dom0_setvcpucontext and dom0_getvcpucontext, 
> would be trivial to convert. 
> - I haven't looked at the ACM hcalls in detail, but I think they would 
> be trivial as well.
 
 The acm hypercalls uses pointers when setting and
reading the policy from the hypervisor and for dumping statistics. A policy
might not necessarily be less than one page.
 
 I don't remember the conversation on the Xen summit
and probably wasn't involved. Would you mind summarizing briefly the discussion?
  
> - xc_readconsolering() would need to copy up to a page of data into
the 
> caller's buffer. 
> - it would introduce a hard restriction on the size of the extent
array 
> in the memory operations (though it's worth noting that the balloon 
> driver already limits this to PAGE_SIZE). 
> - dom0_perfccontrol and dom0_getdomaininfolist would gain restrictions 
> similar to the memory ops. 
>  
> Thoughts? 
>  
> --  
> Hollis Blanchard 
> IBM Linux Technology 
 
 Thanks
 Reiner 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 
 |   
 
 | 
    | 
  
  
    |   | 
    |