From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 02/10] xen: make GUEST_HANDLE_64() and uint64_aligned_t available everywhere Date: Tue, 25 Jun 2013 10:42:49 +0100 Message-ID: <51C96619.8070601@citrix.com> References: <1372095741-27012-1-git-send-email-david.vrabel@citrix.com> <1372095741-27012-3-git-send-email-david.vrabel@citrix.com> <51C9660D02000078000E0364@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51C9660D02000078000E0364@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Tim Deegan , Daniel Kiper , Keir Fraser , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 25/06/13 08:42, Jan Beulich wrote: >>>> On 24.06.13 at 19:42, David Vrabel wrote: >> --- a/xen/include/public/arch-x86/xen-x86_32.h >> +++ b/xen/include/public/arch-x86/xen-x86_32.h >> @@ -91,8 +91,7 @@ >> #define machine_to_phys_mapping ((unsigned long *)MACH2PHYS_VIRT_START) >> #endif >> >> -/* 32-/64-bit invariability for control interfaces (domctl/sysctl). */ >> -#if defined(__XEN__) || defined(__XEN_TOOLS__) >> +/* 32-/64-bit invariability. */ >> #undef ___DEFINE_XEN_GUEST_HANDLE >> #define ___DEFINE_XEN_GUEST_HANDLE(name, type) \ >> typedef struct { type *p; } \ >> @@ -107,7 +106,6 @@ >> #define uint64_aligned_t uint64_t __attribute__((aligned(8))) > > This line is the reason why such a change is not acceptable: We > require the headers to not use gcc extensions outside of regions > guarded by dependencies on __XEN__ and/or __XEN_TOOLS__ (which > we know/require will always be built by gcc compatible tool chains). I did this because this is identical to what ARM is doing. I think we do what a guest handle type that is always 64 bits long. For x86, perhaps something like (but with a better name): #define ___DEFINE_XEN_GUEST_HANDLE(name, type) \ typedef struct { type *p; } \ __guest_handle_ ## name; \ #if defined(__XEN__) || (__XEN_TOOLS__) typedef struct { union { type *p; uint64_aligned_t q; }; } \ __guest_handle_64_ ## name \ #endif typedef struct { union { type *p; uint64_t q; }; } \ __guest_handle_new_ ## name #undef set_xen_guest_handle_raw #define set_xen_guest_handle_raw(hnd, val) \ do { if ( sizeof(hnd) == 8 ) *(uint64_t *)&(hnd) = 0; \ (hnd).p = val; \ } while ( 0 ) #if defined(__XEN__) || (__XEN_TOOLS__) #define uint64_aligned_t uint64_t __attribute__((aligned(8))) #define __XEN_GUEST_HANDLE_64(name) __guest_handle_64_ ## name #define XEN_GUEST_HANDLE_64(name) __XEN_GUEST_HANDLE_64(name) #endif #define __XEN_GUEST_HANDLE_NEW(name) __guest_handle_new_ ## name /* This must be aligned to 8 bytes with padding if necessary. */ #define XEN_GUEST_HANDLE_NEW(name) __XEN_GUEST_HANDLE_NEW(name) >> #define __XEN_GUEST_HANDLE_64(name) __guest_handle_64_ ## name >> #define XEN_GUEST_HANDLE_64(name) __XEN_GUEST_HANDLE_64(name) >> -#endif >> >> #ifndef __ASSEMBLY__ > > I'm afraid you'll need to find a way to do what you want in the > kexec interface with the traditional manual padding approach. This is fine. The kexec interface has the necessary padding and doesn't need the the aligned attribute. David