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