|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|