This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] pointers in hcalls

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] pointers in hcalls
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Tue, 7 Feb 2006 20:20:14 -0500
Delivery-date: Wed, 08 Feb 2006 01:31:17 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

> 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

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>