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

Re: [Xen-devel] [PATCH v3 4/6] xen: introduce XEN_GUEST_HANDLE_PARAM



On Thu, 16 Aug 2012, Jan Beulich wrote:
> >>> On 16.08.12 at 16:50, Stefano Stabellini 
> >>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > --- a/xen/include/public/arch-arm.h
> > +++ b/xen/include/public/arch-arm.h
> > @@ -51,18 +51,34 @@
> >  
> >  #define XEN_HYPERCALL_TAG   0XEA1
> >  
> > +#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
> >  
> >  #ifndef __ASSEMBLY__
> > -#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
> > -    typedef struct { type *p; } __guest_handle_ ## name
> > +#define ___DEFINE_XEN_GUEST_HANDLE(name, type)                  \
> > +    typedef struct { type *p; }                                 \
> > +        __guest_handle_ ## name;                                \
> > +    typedef struct { union { type *p; uint64_aligned_t q; }; }  \
> > +        __guest_handle_64_ ## name;
> 
> Why struct { union { ... } } instead of just union { ... }?

good point :)


> > +/*
> > + * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
> > + * in a struct in memory. On ARM is always 8 bytes sizes and 8 bytes
> > + * aligned.
> > + * XEN_GUEST_HANDLE_PARAM represent a guest pointer, when passed as an
> > + * hypercall argument. It is 4 bytes on aarch and 8 bytes on aarch64.
> > + */
> >  #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
> >      ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
> >      ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> >  #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, 
> > name)
> > -#define __XEN_GUEST_HANDLE(name)        __guest_handle_ ## name
> > +#define __XEN_GUEST_HANDLE(name)        __guest_handle_64_ ## name
> >  #define XEN_GUEST_HANDLE(name)          __XEN_GUEST_HANDLE(name)
> > -#define set_xen_guest_handle_raw(hnd, val)  do { (hnd).p = val; } while (0)
> > +/* this is going to be changes on 64 bit */
> > +#define XEN_GUEST_HANDLE_PARAM(name)    __guest_handle_ ## name
> > +#define set_xen_guest_handle_raw(hnd, val)                  \
> > +    do { if ( sizeof(hnd) == 8 ) *(uint64_t *)&(hnd) = 0;   \
> 
> If you made the "normal" handle a union too, you could avoid
> the explicit cast (which e.g. gcc, when not passed
> -fno-strict-aliasing, will choke on) and instead use (hnd).q (and
> at once avoid the double initialization of the low half).
> 
> Also, the condition to do this could be "sizeof(hnd) > sizeof((hnd).p)",
> usable at once for 64-bit avoiding a full double initialization there.
> 
> > +         (hnd).p = val;                                     \
> 
> In a public header you certainly want to avoid evaluating a
> macro argument twice.

That's a really good suggestion.
I am going to make both handles unions and therefore
set_xen_guest_handle_raw becomes:

#define set_xen_guest_handle_raw(hnd, val)                  \
    do { (hnd).q = 0;                                       \
         (hnd).p = val;                                     \
    } while ( 0 )


> > +    } while ( 0 )
> >  #ifdef __XEN_TOOLS__
> >  #define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0)
> >  #endif
> 
> Seeing the patch I btw realized that there's no easy way to
> avoid having the type as a second argument in the conversion
> macros. Nevertheless I still don't like the explicitly specified type
> there.

I agree, I don't like it either but I couldn't find anything better.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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