On Fri, Jan 26, 2007 at 12:15:44AM +0000, Daniel P. Berrange wrote: > This changeset concerns me in today's xen-unstable > > http://xenbits2.xensource.com/xen-unstable.hg?rev/30af6cfdb05c > > "Make domctl/sysctl interfaces 32-/64-bit invariant. > This kills off a fair amount of unpleasant CONFIG_COMPAT shimming and > avoids needing to keep the compat paths in sync as these interfaces > continue to develop." > > For example > > @@ -81,9 +81,9 @@ struct xen_sysctl_physinfo { > uint32_t sockets_per_node; > uint32_t nr_nodes; > uint32_t cpu_khz; > - uint64_t total_pages; > - uint64_t free_pages; > - uint64_t scrub_pages; > + uint64_aligned_t total_pages; > + uint64_aligned_t free_pages; > + uint64_aligned_t scrub_pages; > uint32_t hw_cap[8]; > > Suggests to me that alignment of thse fields may now have changed on > 32-bit hosts. Well, at least it would if it were not for public/xen.h > doing: > > #define uint64_aligned_t uint64_t So looking more closely, it appears that #define is conditional - ie its only used, if uint64_aligned_t is not already defined by a previous header. On 32-bit arch, we do have such a case in public/arch-x86/xen-x86_32.h #define uint64_aligned_t uint64_t __attribute__((aligned(8))) So, basically on 32-bit systems, any 64-bit fields are now aligned on 8 byte boundaries, instead of 4 byte boundaries. This definitely impacts libvirt's direct hypercalls on 32-bit, because we're reading data from the wrong offsets now - and worse, the mem chunk we pass to the hypercall is probaly too small. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|