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] passing hypercall parameters by pointer

To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] passing hypercall parameters by pointer
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Wed, 17 Aug 2005 17:04:35 -0500
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 17 Aug 2005 22:04:17 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D282BB8@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: IBM Linux Technology Center
References: <A95E2296287EAD4EB592B5DEEFCE0E9D282BB8@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.2
On Wednesday 17 August 2005 15:44, Ian Pratt wrote:
> > Many Xen hypercalls pass mlocked pointers as parameters for
> > both input and output. For example, xc_get_pfn_list() is a
> > nice one with multiple levels of structures/mlocking.
> >
> > Considering just the tools for the moment, those pointers are
> > userspace addresses. Ultimately the hypervisor ends up with
> > that userspace address, from which it reads and writes data.
> > This is OK for x86, since userspace, kernel, and hypervisor
> > all share the same virtual address space (and userspace has
> > carefully mlocked the relevent memory).
> >
> > On PowerPC though, the hypervisor runs in real mode (no MMU
> > translation).
> > Unlike x86, PowerPC exceptions arrive in real mode, and also
> > PowerPC does not force a TLB flush when switching between
> > real and virtual modes. So a virtual address is pretty much
> > worthless as a hypervisor parameter; performing the MMU
> > translation in software is infeasible.
> I think I'd prefer to hide all of this by co-operation between the
> kernel and the hypervisor's copy to/from user.
> The kernel can easily translate a virtual address and length into a list
> of psuedo-phyiscal frame numbers and initial offset. Xen's copy from
> user function can then use this list when doing its work.

Could you elaborate a little?

Consider this structure:
typedef struct {
    /* IN variables. */
    domid_t       domain;
    memory_t      max_pfns;
    void         *buffer;
    /* OUT variables. */
    memory_t      num_pfns;
} dom0_getmemlist_t;

libxc creates this struct and passes it to the kernel, and the kernel doesn't 
know anything about the internals. Are you saying that privcmd_ioctl() should 
look like this?

    switch ( cmd )
        privcmd_hypercall_t hypercall;
        dom0_op_t *op = (dom0_op_t *)&hypercall;
        if ( copy_from_user(&hypercall, (void *)data, sizeof(hypercall)) )
            return -EFAULT;

        /* NEW switch statement: */
        switch (op->cmd)
        case DOM0_GETMEMLIST:
            op->u.getmemlist.buffer = virt_to_phys(op->u.getmemlist.buffer);
        case DOM0_SETDOMAININFO:
        case DOM0_READCONSOLE:

Right now the kernel doesn't peer inside the hypercall structures at all.

Hollis Blanchard
IBM Linux Technology Center

Xen-devel mailing list