Re: [Xen-devel] [PATCH 16/20] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.03.18 at 20:13, <andrew.cooper3@xxxxxxxxxx> wrote:
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2078,7 +2078,8 @@ static void __init find_gnttab_region(struct domain *d,
>       * enough space for a large grant table
>       */
>      kinfo->gnttab_start = __pa(_stext);
> -    kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT;
> +    kinfo->gnttab_size = min_t(unsigned int, opt_max_grant_frames,
> +                               PFN_DOWN(_etext - _stext)) << PAGE_SHIFT;

ARM folks will know whether having the same expression here
and ...

> @@ -695,6 +696,17 @@ void __init start_xen(unsigned long boot_phys_offset,
>      struct domain *dom0;
>      struct xen_domctl_createdomain dom0_cfg = {
>          .max_evtchn_port = -1,
> +
> +        /*
> +         * The region used by Xen on the memory will never be mapped in DOM0
> +         * memory layout. Therefore it can be used for the grant table.
> +         *
> +         * Only use the text section as it's always present and will contain
> +         * enough space for a large grant table
> +         */
> +        .max_grant_frames = min_t(unsigned int, opt_max_grant_frames,
> +                                  PFN_DOWN(_etext - _stext)),

... here isn't risking someone updating one but not the other.

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -547,11 +547,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>          op->domain = d->domain_id;
>          copyback = true;
>  
> -        ret = grant_table_set_limits(d, op->u.createdomain.max_grant_frames,
> -                                     op->u.createdomain.max_maptrack_frames);
> -        if ( !ret )
> -            goto createdomain_fail_late;

With this grant_table_set_limits() can become static, at which point
it becomes questionable whether it wouldn't better be expanded
into its only caller. Oh, looks like that's the subject of patch 17. In
which case non-ARM bits
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel