Re: [Libvir] Dom0 hypercall ABI changes in xen-unstable ?
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 -=|