A Man Without A Country Daniel P. Berrange wrote:
I've been doing some testing with current xen-unstable (ie what will very
shortly be 3.0.5) and came across a whole bunch of things which needed
fixing - some expected, others not expected. The attached patch addresses
the following issues:

As a general question about policy, are we going to support every rev of the HV interface? If Xen change the interface again before 3.0.5 will we support this "pre-3.0.5" and the final interface?

  - Many of the hypercalls have their structs changed so that int64_t
    or 'foo *' members are always 64-bit aligned even on 32-bit platforms.
    This is part of the work to allow 32-bit Dom0/DomU to work on 64-bit
hypervisor.
    For the int64_t types I had to annotate with __attribute__((aligned(8))).
    This did not work for pointer data types, so I for those I had to do
    a more complex hack with

        union {
           foo *v;
           int64_t pad __attribute__((aligned(8)))
        }

What is the problem here?  I did some tests and it seems to work just fine:

/* Test alignment of pointers.
 * Richard Jones <rjones~at~redhat~dot~com>
 */

#include <stdio.h>

#undef offsetof
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

struct s {
  char c;
  //int v;
  //int v __attribute__((aligned(16)));
  int *v __attribute__((aligned(16)));
  //struct s *v __attribute__((aligned(16)));
};

int
main ()
{
  printf ("offset = %d\n", offsetof (struct s, v));
  return 0;
}

$ gcc -Wall -Werror align.c -o align
$ ./align
offset = 16
$ arch
i686
$ gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
Copyright (C) 2003 Free Software Foundation, Inc. [etc]

  - The unified Xen driver broke the GetVCPUs method - it was mistakenly
    checking for return value == 0, instead of > 0. Trivial fix.

Ooops.


I've tested all this on a 32-bit Dom0 running on 32-bit HV, and 64-bit HV,
but not tested a 64-bit Dom0 on 64-bit HV. I'm pretty sure it'll work,but
if anyone is runnning 64-on-64 please test this patch.

I don't have 3.0.5 to test here, but I can possibly test this on Monday. In the meantime I eyeballed the patch and from what I can tell it seems fine.

Rich.

--
Emerging Technologies, Red Hat  http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF     Mobile: +44 7866 314 421

Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

--
Libvir-list mailing list
[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to