WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] pointers in hcalls



hollisb@xxxxxxxxxxxxxxxxxxxxxxx wrote on 02/08/2006 12:14:01 AM:

> On Tue, 2006-02-07 at 20:20 -0500, Reiner Sailer wrote:
> >
> > 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?
>
> (Please CC me on replies.)
sorry.


> The domains (especially the management tools in dom0) are passing
> virtual pointers into the hypervisor.
>
> This assumes that the hypervisor is running in the same address space as
> the userland tools. That assumption is not valid on PPC (we run in real
> mode). One other port (x86-64 VT iirc) has the same problem, but since
> an x86 MMU tablewalk is pretty straightforward, they do that to
> translate the address by hand. This is not feasible on PPC.
>
> It would dramatically simplify the problem if these memory areas were
> limited to one page. Once you go over that, the area could be machine
> discontiguous, which greatly complicates Xen's copy_to/from_user().

Thanks. This info is helpful.

> One possibility would be to install ACM policies in chunks (using
> multiple hcalls) followed by a "commit" hcall.

This is a possibility. The chunks can be committed with the last part. The same way we could retrieve the current policy as well as statistic dumps.

>That would introduce some
> concurrency issues though (e.g. installing two multi-page policies at
> once).


Yes, we will need to introduce additional synchronization.
i) The ACM could reject a new policy while it is accumulating another policy. Then we need to protect from "hanging" policy updates where the policy download is never completed and blocks future policy updates.
ii) The ACM could discard ongoing (i.e., not committed) policy loading if a new policy load is started. This works around the "hanging" policy update problem.

> --
> Hollis Blanchard
> IBM Linux Technology Center
>

It's not elegant but if your solution is the one that is being implemented, then we will find a work-around for the ACM policy calls.

Reiner
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>