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 -=|