|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |