Re: [Xen-devel] [PATCH v3 14/14] xen/mm: Provide dummy M2P-related helpers when !CONFIG_HAVE_M2P

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 05/06/2019 12:07, Jan Beulich wrote:
> > > > On 03.06.19 at 18:03, <julien.grall@xxxxxxx> wrote:
> > At the moment, Arm is providing a dummy implementation for the M2P
> > helpers used in common code. However, they are quite isolated and could
> > be used by other architecture in the future. So move all the helpers in
> > xen/mm.h.
> And where's the problem then adding ...
>
> > --- a/xen/include/xen/mm.h
> > +++ b/xen/include/xen/mm.h
> > @@ -655,4 +655,18 @@ static inline void share_xen_page_with_privileged_guests(
> >       share_xen_page_with_guest(page, dom_xen, flags);
> >   }
> >   
> > +/*
> > + * Dummy implementation of M2P-related helpers for common code when
> > + * the architecture doesn't have an M2P.
> > + */
> > +#ifndef CONFIG_HAS_M2P
> > +
> > +#define INVALID_M2P_ENTRY        (~0UL)
> > +#define SHARED_M2P_ENTRY         (~0UL - 1UL)
> > +#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
> > +
> > +static inline void set_pfn_from_mfn(mfn_t mfn, unsigned long pfn) {}
> > +
> > +#endif
> ... mfn_to_gmfn() to this set? Perhaps a declaration without any
> definition anywhere?
The only purpose for this would be to make some code compile and expect the 
compiler to remove it. So I am not in favor of defining mfn_to_gmfn() in any 
form for Arm.
> Also please take the opportunity and drop the unnecessary underscore
> from _e. And actually, shouldn't this uniformly return false? At which
> point you don't even need SHARED_M2P_ENTRY.
I thought about it. But I wasn't sure if there would be any issue with that 
implementation. I am happy to implement SHARED_M2P this way.
Cheers,

--
Julien Grall

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