[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 12/16] xen/mm: Switch common/memory.c to use typesafe MFN



>>> On 14.03.18 at 19:20, <julien.grall@xxxxxxx> wrote:
> @@ -95,11 +101,17 @@ static unsigned int max_order(const struct domain *d)
>      return min(order, MAX_ORDER + 0U);
>  }
>  
> +/* Helper to copy a typesafe MFN to guest */
> +#define copy_mfn_to_guest(hnd, off, mfn)            \
> +    ({                                              \
> +        xen_pfn_t mfn_ = mfn_x(mfn);                \
> +        __copy_to_guest_offset(hnd, off, &mfn_, 1); \
> +    })

However much I dislike introduction of new name space violations,
I think following the global naming principle here is more important:
As a function not validating the address range, this should have
two leading underscores. Also - was there a reason for this not to
be an inline function?

The other thing I notice only now is perhaps a little much too ask
for a mostly mechanical change like this one: All uses of this sit
inside !paging_mode_translate() checks, hence these could do
nothing on ARM and resolve to __copy_to_user() on x86 (with
the type checking suitably lifted to here).

> @@ -132,8 +144,9 @@ static void increase_reservation(struct memop_args *a)
>          if ( !paging_mode_translate(d) &&
>               !guest_handle_is_null(a->extent_list) )
>          {
> -            mfn = page_to_mfn(page);
> -            if ( unlikely(__copy_to_guest_offset(a->extent_list, i, &mfn, 
> 1)) )
> +            mfn_t mfn = page_to_mfn(page);
> +
> +            if ( unlikely(copy_mfn_to_guest(a->extent_list, i, mfn)) )

Can't you avoid the intermediate variable altogether now?

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.