[Libvir] Dom0 hypercall ABI changes in xen-unstable ?

[Daniel P. Berrange]

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