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] [PATCH 2/3] Grant tables v2 implementation.

On Wed, 2011-11-09 at 08:15 +0000, annie.li@xxxxxxxxxx wrote:
> From: Annie Li <annie.li@xxxxxxxxxx>
> 
> Receiver-side copying of packets is based on this implementation, it gives
> better performance and better CPU accounting. It totally supports three types:
> full-page, sub-page and transitive grants.
> 
> However this patch does not cover sub-page and transitive grants, it mainly
> focus on Full-page part and implements grant table V2 interfaces corresponding
> to what already exists in grant table V1, such as: grant table V2
> initialization, mapping, releasing and exported interfaces.
> 
> Each guest can only supports one type of grant table type, every entry in 
> grant
> table should be the same version. It is necessary to set V1 or V2 version 
> before
> initializing the grant table.
> 
> Grant table exported interfaces of V2 are same with those of V1, Xen is
> responsible to judge what grant table version guests are using in every grant
> operation.
> 
> V2 fulfills the same role of V1, and it is totally backwards compitable with 
> V1.
> If dom0 support grant table V2, the guests runing on it can run with either V1
> or V2.
> 
> Signed-off-by: Annie Li <annie.li@xxxxxxxxxx>
> ---
>  arch/x86/xen/grant-table.c |   34 ++++++++-
>  drivers/xen/grant-table.c  |  194 
> +++++++++++++++++++++++++++++++++++++++++---
>  include/xen/grant_table.h  |    6 +-
>  3 files changed, 220 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
> index 65ce508..3e9f936 100644
> --- a/arch/x86/xen/grant-table.c
> +++ b/arch/x86/xen/grant-table.c
> @@ -54,6 +54,17 @@ static int map_pte_fn(pte_t *pte, struct page *pmd_page,
>         return 0;
>  }
> 
> +/*32bits is not enough since Xen supports sparse physical memory*/

What does this mean?

> +static int map_pte_fn_status(pte_t *pte, struct page *pmd_page,
> +                            unsigned long addr, void *data)
> +{
> +       uint64_t **frames = (uint64_t **)data;
> +
> +       set_pte_at(&init_mm, addr, pte, mfn_pte((*frames)[0], PAGE_KERNEL));
> +       (*frames)++;
> +       return 0;
> +}

Isn't this function identical to map_pte_fn?

> +
>  static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
>                         unsigned long addr, void *data)
>  {

> @@ -630,6 +756,44 @@ static int gnttab_map_status_v1(unsigned int nr_gframes)
>         return 0;
>  }
> 
> +static int gnttab_map_status_v2(unsigned int nr_gframes)
> +{
> +       uint64_t *sframes;
> +       unsigned int nr_sframes;
> +       struct gnttab_get_status_frames getframes;
> +       int rc;
> +
> +       nr_sframes = nr_status_frames(nr_gframes);
> +
> +       /* No need for kzalloc as it is initialized in following hyercall

                                                                   hypercall

> +        * GNTTABOP_get_status_frames.
> +        */
> +       sframes = kmalloc(nr_sframes  * sizeof(uint64_t), GFP_ATOMIC);
> +       if (!sframes)
> +               return -ENOMEM;
> +
> +       getframes.dom        = DOMID_SELF;
> +       getframes.nr_frames  = nr_sframes;
> +       set_xen_guest_handle(getframes.frame_list, sframes);
> +
> +       rc = HYPERVISOR_grant_table_op(GNTTABOP_get_status_frames,
> +                                      &getframes, 1);
> +       if (rc == -ENOSYS) {
> +               kfree(sframes);
> +               return -ENOSYS;
> +       }
> +
> +       BUG_ON(rc || getframes.status);
> +
> +       rc = arch_gnttab_map_status(sframes, nr_sframes,
> +                                   
> nr_status_frames(gnttab_max_grant_frames()),
> +                                   &grstatus);
> +       BUG_ON(rc);
> +       kfree(sframes);
> +
> +       return 0;
> +}
> +
>  static int gnttab_map_status(unsigned int nr_gframes)
>  {
>         return gnttab_interface._gnttab_map_status(nr_gframes);
> @@ -666,6 +830,9 @@ static int gnttab_map(unsigned int start_idx, unsigned 
> int end_idx)
>                 return rc;
>         }
> 
> +       /* No need for kzalloc as it is initialized in following hyercall

"hypercall" again

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel