Folks, A new release candidate for 3.2.0 has just been checked into the xen-unstable tree. It''s available from staging and will be in the main tree when it has passed internal regression tests. Meanwhile, in preparation for 3.1.3, please let me know if there are any further patches from xen-unstable that should be backported into the 3.1 branch. You can pull the xen-3.1-testing.hg repository to see what has already been backported. Thanks, Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Any chance the sequence of timer/tick fixes that you, Dave Winchell, Ben Guthro, Haitao Shan, and Eddie Dong were discussing/developing over the last two months could get into 3.1.3? Clocks that gain time can cause some pretty nasty difficult-to-diagnose real customer problems. Thanks, Dan> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of Keir Fraser > Sent: Wednesday, December 19, 2007 9:01 AM > To: xen-devel > Subject: [Xen-devel] 3.1.x and 3.2.x releases > > > Folks, > > A new release candidate for 3.2.0 has just been checked into the > xen-unstable tree. It''s available from staging and will be in > the main tree > when it has passed internal regression tests. > > Meanwhile, in preparation for 3.1.3, please let me know if > there are any > further patches from xen-unstable that should be backported > into the 3.1 > branch. You can pull the xen-3.1-testing.hg repository to see what has > already been backported. > > Thanks, > Keir > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Dec 19, 2007 at 04:00:57PM +0000, Keir Fraser wrote:> Meanwhile, in preparation for 3.1.3, please let me know if there are any > further patches from xen-unstable that should be backported into the 3.1 > branch. You can pull the xen-3.1-testing.hg repository to see what has > already been backported.My 3.1 testing has revealed a problem when rapidly rebooting a single domU. Eventually, xend gets a wrong type response in xs.c (it''s expecting a reply to XS_READ, and it gets a reply to XS_TRANSACTION_END). This breaks everything horribly, as xend is very poor at recovering from an error like this. I''m still looking at it, but I wonder if people are doing a similar test and if anyone else has ever seen it. The classic symptom is something like: # xm list Error: (2, ''No such file or directory'') Usage: xm list [options] [Domain, ...] Or more often EBADF regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thursday, December 20, 2007 12:01 AM xen-devel-bounces@lists.xensource.com wrote:> Folks, > > A new release candidate for 3.2.0 has just been checked into the > xen-unstable tree. It''s available from staging and will be in > the main tree > when it has passed internal regression tests.We caught a new issue for Xen 3.2 RC2. HVM domain restore failed and also local live mirgration failed. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1125 Best Regards, Yongkang You _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Dec 20, 2007 at 11:58:24AM +0800, You, Yongkang wrote:> > A new release candidate for 3.2.0 has just been checked into the > > xen-unstable tree. It''s available from staging and will be in > > the main tree > > when it has passed internal regression tests. > > We caught a new issue for Xen 3.2 RC2. > > HVM domain restore failed and also local live mirgration failed. > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1125I''ve done some very basic testing (again, no HVM) on Solaris bits based on rc2, and it doesn''t seem to have got worse. regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Done. K. On 19/12/07 17:22, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:> Any chance the sequence of timer/tick fixes that you, Dave Winchell, > Ben Guthro, Haitao Shan, and Eddie Dong were discussing/developing > over the last two months could get into 3.1.3? Clocks that gain time > can cause some pretty nasty difficult-to-diagnose real customer > problems. > > Thanks, > Dan > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of Keir Fraser >> Sent: Wednesday, December 19, 2007 9:01 AM >> To: xen-devel >> Subject: [Xen-devel] 3.1.x and 3.2.x releases >> >> >> Folks, >> >> A new release candidate for 3.2.0 has just been checked into the >> xen-unstable tree. It''s available from staging and will be in >> the main tree >> when it has passed internal regression tests. >> >> Meanwhile, in preparation for 3.1.3, please let me know if >> there are any >> further patches from xen-unstable that should be backported >> into the 3.1 >> branch. You can pull the xen-3.1-testing.hg repository to see what has >> already been backported. >> >> Thanks, >> Keir >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks Keir... but in trying to test this, I find that timer_mode seems to be displayed in sxp debug output in xend.log for xen-unstable, but I don''t see sxp output for timer_mode in xend.log for xen-3.1-testing (cset 15564). Does timer_mode get properly set and passed down to xen in xen-3.1-testing simply by adding a (e.g.) "timer_mode=3" line in the config file? If so, is there another way I can verify that? Thanks, Dan> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of Keir Fraser > Sent: Thursday, December 20, 2007 3:26 AM > To: dan.magenheimer@oracle.com; xen-devel > Subject: Re: [Xen-devel] 3.1.x and 3.2.x releases > > > Done. > > K. > > > On 19/12/07 17:22, "Dan Magenheimer" > <dan.magenheimer@oracle.com> wrote: > > > Any chance the sequence of timer/tick fixes that you, Dave Winchell, > > Ben Guthro, Haitao Shan, and Eddie Dong were discussing/developing > > over the last two months could get into 3.1.3? Clocks that > gain time > > can cause some pretty nasty difficult-to-diagnose real customer > > problems. > > > > Thanks, > > Dan > > > >> -----Original Message----- > >> From: xen-devel-bounces@lists.xensource.com > >> [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of > Keir Fraser > >> Sent: Wednesday, December 19, 2007 9:01 AM > >> To: xen-devel > >> Subject: [Xen-devel] 3.1.x and 3.2.x releases > >> > >> > >> Folks, > >> > >> A new release candidate for 3.2.0 has just been checked into the > >> xen-unstable tree. It''s available from staging and will be in > >> the main tree > >> when it has passed internal regression tests. > >> > >> Meanwhile, in preparation for 3.1.3, please let me know if > >> there are any > >> further patches from xen-unstable that should be backported > >> into the 3.1 > >> branch. You can pull the xen-3.1-testing.hg repository to > see what has > >> already been backported. > >> > >> Thanks, > >> Keir > >> > >> > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xensource.com > >> http://lists.xensource.com/xen-devel > >> > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I only did a straightforward port of the xend parts, without much testing. You could add tracing to the hvm_param hypercall in xen/arch/x86/hvm/hvm.c, and see whether the timer mode is being set for your HVM guest that way. -- Keir On 26/12/07 19:53, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:> Thanks Keir... but in trying to test this, I find that timer_mode seems to be > displayed in sxp debug output in xend.log for xen-unstable, but I don''t see > sxp output for timer_mode in xend.log for xen-3.1-testing (cset 15564). Does > timer_mode get properly set and passed down to xen in xen-3.1-testing simply > by adding a (e.g.) "timer_mode=3" line in the config file? If so, is there > another way I can verify that? > > Thanks, > Dan > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of Keir Fraser >> Sent: Thursday, December 20, 2007 3:26 AM >> To: dan.magenheimer@oracle.com; xen-devel >> Subject: Re: [Xen-devel] 3.1.x and 3.2.x releases >> >> >> Done. >> >> K. >> >> >> On 19/12/07 17:22, "Dan Magenheimer" >> <dan.magenheimer@oracle.com> wrote: >> >>> Any chance the sequence of timer/tick fixes that you, Dave Winchell, >>> Ben Guthro, Haitao Shan, and Eddie Dong were discussing/developing >>> over the last two months could get into 3.1.3? Clocks that >> gain time >>> can cause some pretty nasty difficult-to-diagnose real customer >>> problems. >>> >>> Thanks, >>> Dan >>> >>>> -----Original Message----- >>>> From: xen-devel-bounces@lists.xensource.com >>>> [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of >> Keir Fraser >>>> Sent: Wednesday, December 19, 2007 9:01 AM >>>> To: xen-devel >>>> Subject: [Xen-devel] 3.1.x and 3.2.x releases >>>> >>>> >>>> Folks, >>>> >>>> A new release candidate for 3.2.0 has just been checked into the >>>> xen-unstable tree. It''s available from staging and will be in >>>> the main tree >>>> when it has passed internal regression tests. >>>> >>>> Meanwhile, in preparation for 3.1.3, please let me know if >>>> there are any >>>> further patches from xen-unstable that should be backported >>>> into the 3.1 >>>> branch. You can pull the xen-3.1-testing.hg repository to >> see what has >>>> already been backported. >>>> >>>> Thanks, >>>> Keir >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi; 19 Ara 2007 Çar tarihinde, Keir Fraser şunları yazmıştı:> Meanwhile, in preparation for 3.1.3, please let me know if there are any > further patches from xen-unstable that should be backported into the 3.1 > branch. You can pull the xen-3.1-testing.hg repository to see what has > already been backported.I''m getting following build error with libvirt-0.4.0 on latest xen-3.1-testing.hg (i''m using gcc-3.4.6). I found [1] in xen-changelog mailing list while searching but it''s already backported to xen-3.1-testing, is another patch needed or i''m missing something? [...] make[2]:`/var/pisi/libvirt-0.4.0-3/work/libvirt-0.4.0/src'' dizinine giriliyor /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include -I../include -I../qemud -I/usr/include/libxml2 -DBINDIR=\""/usr/libexec"\" -DSBINDIR=\""/usr/sbin"\" -DSYSCONF_DIR="\"/etc\"" -DLOCALEBASEDIR=\""/usr/share/locale"\" -DLOCAL_STATE_DIR=\""/var/lib"\" -DGETTEXT_PACKAGE=\"libvirt\" -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables -DWITH_QEMU -DWITH_TEST -DWITH_REMOTE -DWITH_XEN -mtune=i686 -O2 -pipe -fomit-frame-pointer -MT libvirt_la-xen_unified.lo -MD -MP -MF .deps/libvirt_la-xen_unified.Tpo -c -o libvirt_la-xen_unified.lo `test -f ''xen_unified.c'' || echo ''./''`xen_unified.c gcc -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include -I../include -I../qemud -I/usr/include/libxml2 -DBINDIR=\"/usr/libexec\" -DSBINDIR=\"/usr/sbin\" -DSYSCONF_DIR=\"/etc\" -DLOCALEBASEDIR=\"/usr/share/locale\" -DLOCAL_STATE_DIR=\"/var/lib\" -DGETTEXT_PACKAGE=\"libvirt\" -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables -DWITH_QEMU -DWITH_TEST -DWITH_REMOTE -DWITH_XEN -mtune=i686 -O2 -pipe -fomit-frame-pointer -MT libvirt_la-xen_unified.lo -MD -MP -MF .deps/libvirt_la-xen_unified.Tpo -c xen_unified.c -fPIC -DPIC -o .libs/libvirt_la-xen_unified.o In file included from /usr/include/xen/dom0_ops.h:31, from xen_unified.c:29: /usr/include/xen/xen.h:580: error: syntax error before "char" /usr/include/xen/xen.h:581: error: syntax error before "short" /usr/include/xen/xen.h:582: error: syntax error before "int" /usr/include/xen/xen.h:583: error: syntax error before "long" In file included from /usr/include/xen/dom0_ops.h:32, from xen_unified.c:29: /usr/include/xen/platform.h:149: error: syntax error before "__guest_handle_unsigned" /usr/include/xen/platform.h:151: error: syntax error before ''}'' token /usr/include/xen/platform.h:152: error: syntax error before ''}'' token /usr/include/xen/platform.h:166: error: field `firmware_info'' has incomplete type make[2]: *** [libvirt_la-xen_unified.lo] Hata 1 make[2]: `/var/pisi/libvirt-0.4.0-3/work/libvirt-0.4.0/src'' dizininden çıkılıyor make[1]: *** [all-recursive] Hata 1 make[1]: `/var/pisi/libvirt-0.4.0-3/work/libvirt-0.4.0'' dizininden çıkılıyor make: *** [all] Hata 2 [...] [1] http://lists.xensource.com/archives/html/xen-changelog/2007-09/msg00095.html Cheers -- S.Çağlar Onur <caglar@pardus.org.tr> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It''s not obvious what the problem is. DEFINE_XEN_GUEST_HANDLE() is defined at that point in xen.h because we have used it earlier. This is also true for uint8_t, uint16_t, etc. You''ll have to do a bit more digging (e.g., use gcc -E option to get the post-processed source, and see if that shows anything obviously wrong). -- Keir On 27/12/07 23:37, "S.Çağlar Onur" <caglar@pardus.org.tr> wrote:> Hi; > > 19 Ara 2007 Çar tarihinde, Keir Fraser şunları yazmıştı: >> Meanwhile, in preparation for 3.1.3, please let me know if there are any >> further patches from xen-unstable that should be backported into the 3.1 >> branch. You can pull the xen-3.1-testing.hg repository to see what has >> already been backported. > > I''m getting following build error with libvirt-0.4.0 on latest > xen-3.1-testing.hg (i''m using gcc-3.4.6). > > I found [1] in xen-changelog mailing list while searching but it''s already > backported to xen-3.1-testing, is another patch needed or i''m missing > something? > > [...] > make[2]:`/var/pisi/libvirt-0.4.0-3/work/libvirt-0.4.0/src'' dizinine giriliyor > /bin/sh ../libtool --tag=CC --mode=compile > gcc -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include > -I../include -I../qemud -I/usr/include/libxml2 -DBINDIR=\""/usr/libexec"\" > -DSBINDIR=\""/usr/sbin"\" -DSYSCONF_DIR="\"/etc\"" > -DLOCALEBASEDIR=\""/usr/share/locale"\" -DLOCAL_STATE_DIR=\""/var/lib"\" > -DGETTEXT_PACKAGE=\"libvirt\" -Wall -Wformat -Wformat-security > -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow > -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline > -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fasynchronous-unwind-tables -DWITH_QEMU -DWITH_TEST -DWITH_REMOTE -DWITH_XEN > -mtune=i686 -O2 -pipe -fomit-frame-pointer -MT > libvirt_la-xen_unified.lo -MD -MP -MF .deps/libvirt_la-xen_unified.Tpo -c -o > libvirt_la-xen_unified.lo `test -f ''xen_unified.c'' || echo ''./''`xen_unified.c > > gcc -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include > -I../include -I../qemud -I/usr/include/libxml2 -DBINDIR=\"/usr/libexec\" > -DSBINDIR=\"/usr/sbin\" -DSYSCONF_DIR=\"/etc\" > -DLOCALEBASEDIR=\"/usr/share/locale\" -DLOCAL_STATE_DIR=\"/var/lib\" > -DGETTEXT_PACKAGE=\"libvirt\" -Wall -Wformat -Wformat-security > -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow > -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline > -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fasynchronous-unwind-tables -DWITH_QEMU -DWITH_TEST -DWITH_REMOTE -DWITH_XEN > -mtune=i686 -O2 -pipe -fomit-frame-pointer -MT > libvirt_la-xen_unified.lo -MD -MP -MF .deps/libvirt_la-xen_unified.Tpo -c > xen_unified.c -fPIC -DPIC -o .libs/libvirt_la-xen_unified.o > In file included from /usr/include/xen/dom0_ops.h:31, > from xen_unified.c:29: > /usr/include/xen/xen.h:580: error: syntax error before "char" > /usr/include/xen/xen.h:581: error: syntax error before "short" > /usr/include/xen/xen.h:582: error: syntax error before "int" > /usr/include/xen/xen.h:583: error: syntax error before "long" > In file included from /usr/include/xen/dom0_ops.h:32, > from xen_unified.c:29: > /usr/include/xen/platform.h:149: error: syntax error > before "__guest_handle_unsigned" > /usr/include/xen/platform.h:151: error: syntax error before ''}'' token > /usr/include/xen/platform.h:152: error: syntax error before ''}'' token > /usr/include/xen/platform.h:166: error: field `firmware_info'' has incomplete > type > make[2]: *** [libvirt_la-xen_unified.lo] Hata 1 > make[2]: `/var/pisi/libvirt-0.4.0-3/work/libvirt-0.4.0/src'' dizininden > çıkılıyor > make[1]: *** [all-recursive] Hata 1 > make[1]: `/var/pisi/libvirt-0.4.0-3/work/libvirt-0.4.0'' dizininden çıkılıyor > make: *** [all] Hata 2 > [...] > > [1] > http://lists.xensource.com/archives/html/xen-changelog/2007-09/msg00095.html > > Cheers_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Keir; 28 Ara 2007 Cum tarihinde, Keir Fraser şunları yazmıştı:> It''s not obvious what the problem is. DEFINE_XEN_GUEST_HANDLE() is defined > at that point in xen.h because we have used it earlier. This is also true > for uint8_t, uint16_t, etc. You''ll have to do a bit more digging (e.g., use > gcc -E option to get the post-processed source, and see if that shows > anything obviously wrong).Seems like [...] DEFINE_XEN_GUEST_HANDLE(uint8_t); DEFINE_XEN_GUEST_HANDLE(uint16_t); DEFINE_XEN_GUEST_HANDLE(uint32_t); DEFINE_XEN_GUEST_HANDLE(uint64_t); [...] in xen.h converted [...] typedef unsigned char * __guest_handle_unsigned char; typedef unsigned short int * __guest_handle_unsigned short int; typedef unsigned int * __guest_handle_unsigned int; typedef unsigned long long int * __guest_handle_unsigned long long int; [...] and [...] XEN_GUEST_HANDLE(uint8_t) edid; [...] in platform.h converted [...] __guest_handle_unsigned char edid; [...] which causes the build errors. Cheers -- S.Çağlar Onur <caglar@pardus.org.tr> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Oh, it''s because your stdint.h type definitions are macros rather than typedefs. I believe the C spec requires them to be typedef names (Section 7.18 of the C99 draft spec). It looks like the problem stems from the stdint.h supplied with gnulib, included in libvirt-0.4.0. Why does libvirt require its own stdint.h? I''m pretty sure you''d have the same problem building against the 3.2.0-rc public headers. -- Keir On 28/12/07 10:17, "S.Çağlar Onur" <caglar@pardus.org.tr> wrote:> Hi Keir; > > 28 Ara 2007 Cum tarihinde, Keir Fraser şunları yazmıştı: >> It''s not obvious what the problem is. DEFINE_XEN_GUEST_HANDLE() is defined >> at that point in xen.h because we have used it earlier. This is also true >> for uint8_t, uint16_t, etc. You''ll have to do a bit more digging (e.g., use >> gcc -E option to get the post-processed source, and see if that shows >> anything obviously wrong). > > Seems like > > [...] > DEFINE_XEN_GUEST_HANDLE(uint8_t); > DEFINE_XEN_GUEST_HANDLE(uint16_t); > DEFINE_XEN_GUEST_HANDLE(uint32_t); > DEFINE_XEN_GUEST_HANDLE(uint64_t); > [...] > > in xen.h converted > > [...] > typedef unsigned char * __guest_handle_unsigned char; > typedef unsigned short int * __guest_handle_unsigned short int; > typedef unsigned int * __guest_handle_unsigned int; > typedef unsigned long long int * __guest_handle_unsigned long long int; > [...] > > and > > [...] > XEN_GUEST_HANDLE(uint8_t) edid; > [...] > > in platform.h converted > > [...] > __guest_handle_unsigned char edid; > [...] > > which causes the build errors. > > Cheers_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Dec 28, 2007 at 01:16:50PM +0000, Keir Fraser wrote:> Oh, it''s because your stdint.h type definitions are macros rather than > typedefs. I believe the C spec requires them to be typedef names (Section > 7.18 of the C99 draft spec). It looks like the problem stems from the > stdint.h supplied with gnulib, included in libvirt-0.4.0. Why does libvirt > require its own stdint.h?Note this same bogus header breaks Solaris full stop (I think we have a patch for it, but I''m not sure) regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 28/12/07 14:55, "John Levon" <levon@movementarian.org> wrote:>> Oh, it''s because your stdint.h type definitions are macros rather than >> typedefs. I believe the C spec requires them to be typedef names (Section >> 7.18 of the C99 draft spec). It looks like the problem stems from the >> stdint.h supplied with gnulib, included in libvirt-0.4.0. Why does libvirt >> require its own stdint.h? > > Note this same bogus header breaks Solaris full stop (I think we have a > patch for it, but I''m not sure)Well, we could call the handles uint8, uint16, and so on. That shouldn''t clash in the macro namespace. I''ll see how invasive that is. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Dec 28, 2007 at 01:16:50PM +0000, Keir Fraser wrote:> Oh, it''s because your stdint.h type definitions are macros rather than > typedefs. I believe the C spec requires them to be typedef names (Section > 7.18 of the C99 draft spec). It looks like the problem stems from the > stdint.h supplied with gnulib, included in libvirt-0.4.0. Why does libvirt > require its own stdint.h?The gnulib stuff is for portability. The stdint.h in the gnulib/ directory of libvirt will only be used on OS where there is no stdint.h present in the regular /usr/include. Can someone tell me what OS / platform the libvirt compile errors were occurring on. stdint.h is a pretty common thing so I''d only expect it to be have been used when building libvirt on Windows, certainly not when on Linux. Regards, 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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 28/12/07 15:47, "Daniel P. Berrange" <berrange@redhat.com> wrote:> On Fri, Dec 28, 2007 at 01:16:50PM +0000, Keir Fraser wrote: >> Oh, it''s because your stdint.h type definitions are macros rather than >> typedefs. I believe the C spec requires them to be typedef names (Section >> 7.18 of the C99 draft spec). It looks like the problem stems from the >> stdint.h supplied with gnulib, included in libvirt-0.4.0. Why does libvirt >> require its own stdint.h? > > The gnulib stuff is for portability. The stdint.h in the gnulib/ directory > of libvirt will only be used on OS where there is no stdint.h present in > the regular /usr/include. > > Can someone tell me what OS / platform the libvirt compile errors were > occurring on. stdint.h is a pretty common thing so I''d only expect it > to be have been used when building libvirt on Windows, certainly not when > on Linux.Well, I hopefully fixed it now anyway, both in 3.1-testing and unstable. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hmmm....
I tried something a bit more dramatic. In arch/x86/hvm/hvm.c, in the
case HVM_PARAM_TIMER_MODE, I changed the "goto param_fail;" to
"panic("BAD HVMPTM");" and added "timer_mode=6" in
the config file, but
the panic was not triggered. But the same code/config change in
xen-unstable DOES panic.
Am I missing something in configuring this for xen-3.1-testing? Or
perhaps the 3.1 patch just isn''t passing timer_mode down properly?
Thanks,
Dan
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of Keir Fraser
> Sent: Wednesday, December 26, 2007 4:08 PM
> To: dan.magenheimer@oracle.com; xen-devel
> Subject: Re: [Xen-devel] 3.1.x and 3.2.x releases
>
>
> I only did a straightforward port of the xend parts, without
> much testing.
> You could add tracing to the hvm_param hypercall in
> xen/arch/x86/hvm/hvm.c,
> and see whether the timer mode is being set for your HVM
> guest that way.
>
> -- Keir
>
> On 26/12/07 19:53, "Dan Magenheimer"
> <dan.magenheimer@oracle.com> wrote:
>
> > Thanks Keir... but in trying to test this, I find that
> timer_mode seems to be
> > displayed in sxp debug output in xend.log for xen-unstable,
> but I don''t see
> > sxp output for timer_mode in xend.log for xen-3.1-testing
> (cset 15564). Does
> > timer_mode get properly set and passed down to xen in
> xen-3.1-testing simply
> > by adding a (e.g.) "timer_mode=3" line in the config file?
> If so, is there
> > another way I can verify that?
> >
> > Thanks,
> > Dan
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xensource.com
> >> [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of
> Keir Fraser
> >> Sent: Thursday, December 20, 2007 3:26 AM
> >> To: dan.magenheimer@oracle.com; xen-devel
> >> Subject: Re: [Xen-devel] 3.1.x and 3.2.x releases
> >>
> >>
> >> Done.
> >>
> >> K.
> >>
> >>
> >> On 19/12/07 17:22, "Dan Magenheimer"
> >> <dan.magenheimer@oracle.com> wrote:
> >>
> >>> Any chance the sequence of timer/tick fixes that you,
> Dave Winchell,
> >>> Ben Guthro, Haitao Shan, and Eddie Dong were
discussing/developing
> >>> over the last two months could get into 3.1.3? Clocks that
> >> gain time
> >>> can cause some pretty nasty difficult-to-diagnose real
customer
> >>> problems.
> >>>
> >>> Thanks,
> >>> Dan
> >>>
> >>>> -----Original Message-----
> >>>> From: xen-devel-bounces@lists.xensource.com
> >>>> [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of
> >> Keir Fraser
> >>>> Sent: Wednesday, December 19, 2007 9:01 AM
> >>>> To: xen-devel
> >>>> Subject: [Xen-devel] 3.1.x and 3.2.x releases
> >>>>
> >>>>
> >>>> Folks,
> >>>>
> >>>> A new release candidate for 3.2.0 has just been checked
into the
> >>>> xen-unstable tree. It''s available from staging
and will be in
> >>>> the main tree
> >>>> when it has passed internal regression tests.
> >>>>
> >>>> Meanwhile, in preparation for 3.1.3, please let me know if
> >>>> there are any
> >>>> further patches from xen-unstable that should be
backported
> >>>> into the 3.1
> >>>> branch. You can pull the xen-3.1-testing.hg repository to
> >> see what has
> >>>> already been backported.
> >>>>
> >>>> Thanks,
> >>>> Keir
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Xen-devel mailing list
> >>>> Xen-devel@lists.xensource.com
> >>>> http://lists.xensource.com/xen-devel
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xensource.com
> >>> http://lists.xensource.com/xen-devel
> >>
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >>
> >
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
28 Ara 2007 Cum tarihinde, Daniel P. Berrange şunları yazmıştı:> On Fri, Dec 28, 2007 at 01:16:50PM +0000, Keir Fraser wrote: > > Oh, it''s because your stdint.h type definitions are macros rather than > > typedefs. I believe the C spec requires them to be typedef names (Section > > 7.18 of the C99 draft spec). It looks like the problem stems from the > > stdint.h supplied with gnulib, included in libvirt-0.4.0. Why does > > libvirt require its own stdint.h? > > The gnulib stuff is for portability. The stdint.h in the gnulib/ directory > of libvirt will only be used on OS where there is no stdint.h present in > the regular /usr/include. > > Can someone tell me what OS / platform the libvirt compile errors were > occurring on. stdint.h is a pretty common thing so I''d only expect it > to be have been used when building libvirt on Windows, certainly not when > on Linux.But i''m try to compile libvirt on Linux which has stdint.h in regular /usr/include :) -- S.Çağlar Onur <caglar@pardus.org.tr> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Dec 28, 2007 9:55 AM, John Levon <levon@movementarian.org> wrote:> On Fri, Dec 28, 2007 at 01:16:50PM +0000, Keir Fraser wrote: > > > Oh, it''s because your stdint.h type definitions are macros rather than > > typedefs. I believe the C spec requires them to be typedef names > (Section > > 7.18 of the C99 draft spec). It looks like the problem stems from the > > stdint.h supplied with gnulib, included in libvirt-0.4.0. Why does > libvirt > > require its own stdint.h? > > Note this same bogus header breaks Solaris full stop (I think we have a > patch for it, but I''m not sure)I did hit this when compiling 0.4.0 on Solaris. I hacked around this with the following patch, but figured I''d spend more time figuring out a better solution before sending something upstream. Still, it may be useful to some. -Ryan diff --git a/configure b/configure --- a/configure +++ b/configure @@ -36255,7 +36255,7 @@ fi CFLAGS="$old_cflags" LDFLAGS="$old_ldflags" -GNUTLS_CFLAGS+GNUTLS_CFLAGS=-D_GL_JUST_INCLUDE_SYSTEM_STDINT_H GNUTLS_LIBS if test "x$PKG_CONFIG" != "x" ; then diff --git a/proxy/Makefile.in b/proxy/Makefile.in --- a/proxy/Makefile.in +++ b/proxy/Makefile.in @@ -154,7 +154,7 @@ BITSIZEOF_WINT_T = @BITSIZEOF_WINT_T@ BRCTL = @BRCTL@ CC = @CC@ CCDEPMODE = @CCDEPMODE@ -CFLAGS = @CFLAGS@ +CFLAGS = @CFLAGS@ -D_GL_JUST_INCLUDE_SYSTEM_STDINT_H COMPILER_FLAGS = @COMPILER_FLAGS@ COVERAGE_CFLAGS = @COVERAGE_CFLAGS@ COVERAGE_LDFLAGS = @COVERAGE_LDFLAGS@> > > regards > john > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 28/12/07 22:52, "Dan Magenheimer" <dan.magenheimer@Oracle.com> wrote:> Hmmm.... > > I tried something a bit more dramatic. In arch/x86/hvm/hvm.c, in the > case HVM_PARAM_TIMER_MODE, I changed the "goto param_fail;" to > "panic("BAD HVMPTM");" and added "timer_mode=6" in the config file, but > the panic was not triggered. But the same code/config change in > xen-unstable DOES panic. > > Am I missing something in configuring this for xen-3.1-testing? Or > perhaps the 3.1 patch just isn''t passing timer_mode down properly?Line 1542 of XendDomainInfo.py should be passing the mode down to Xen. Presumably that is not working. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/12/07 09:18, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:>> I tried something a bit more dramatic. In arch/x86/hvm/hvm.c, in the >> case HVM_PARAM_TIMER_MODE, I changed the "goto param_fail;" to >> "panic("BAD HVMPTM");" and added "timer_mode=6" in the config file, but >> the panic was not triggered. But the same code/config change in >> xen-unstable DOES panic. >> >> Am I missing something in configuring this for xen-3.1-testing? Or >> perhaps the 3.1 patch just isn''t passing timer_mode down properly? > > Line 1542 of XendDomainInfo.py should be passing the mode down to Xen. > Presumably that is not working.Also, I have a suspicion that timer_mode won''t survive a save/restore of an HVM guest, either in unstable or in 3.1-testing. I haven''t confirmed this though. But there''s no code to do it, so unless it happens automagically... -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi; 28 Ara 2007 Cum tarihinde, Keir Fraser şunları yazmıştı:> Well, I hopefully fixed it now anyway, both in 3.1-testing and unstable.Although xen-unstable has following caglar@zangetsu xen-unstable.hg $ hg log -r ad0f20f5590a changeset: 16674:ad0f20f5590a user: Keir Fraser <keir.fraser@citrix.com> date: Fri Dec 28 15:44:51 2007 +0000 summary: Rename uintN_t guest handles to uintN, to avoid nameclash with uintN_t 3.1-testing still not updated, caglar@zangetsu xen-3.1-testing.hg $ hg log -r tip changeset: 15564:9093b433fa5c tag: tip user: Keir Fraser <keir.fraser@citrix.com> date: Thu Dec 20 14:57:03 2007 +0000 summary: xend: Clean up hvm_build Python wrapper. Python code can get/set hvm Did you forgot to push or 3.1-testing commits waits for internal testing? Cheers -- S.Çağlar Onur <caglar@pardus.org.tr> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> >> Am I missing something in configuring this for xen-3.1-testing? Or > >> perhaps the 3.1 patch just isn''t passing timer_mode down properly? > > > > Line 1542 of XendDomainInfo.py should be passing the mode > down to Xen. > > Presumably that is not working. > > Also, I have a suspicion that timer_mode won''t survive a > save/restore of an > HVM guest, either in unstable or in 3.1-testing. I haven''t > confirmed this > though. But there''s no code to do it, so unless it happens > automagically...On second look, it works fine. (My fault... multiple python directories again :-( Also, looks to me like timer_mode across save/restore is working fine too. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It''s in the staging tree (http://xenbits.xensource.com/staging/xen-3.1-testing.hg). I haven''t seen internal tests run for a while so they might be stalled for some reason. I''ll take a look in the next day or so. -- Keir On 1/1/08 16:31, "S.Çağlar Onur" <caglar@pardus.org.tr> wrote:> Hi; > > 28 Ara 2007 Cum tarihinde, Keir Fraser şunları yazmıştı: >> Well, I hopefully fixed it now anyway, both in 3.1-testing and unstable. > > Although xen-unstable has following > > caglar@zangetsu xen-unstable.hg $ hg log -r ad0f20f5590a > changeset: 16674:ad0f20f5590a > user: Keir Fraser <keir.fraser@citrix.com> > date: Fri Dec 28 15:44:51 2007 +0000 > summary: Rename uintN_t guest handles to uintN, to avoid nameclash with > uintN_t > > 3.1-testing still not updated, > > caglar@zangetsu xen-3.1-testing.hg $ hg log -r tip > changeset: 15564:9093b433fa5c > tag: tip > user: Keir Fraser <keir.fraser@citrix.com> > date: Thu Dec 20 14:57:03 2007 +0000 > summary: xend: Clean up hvm_build Python wrapper. Python code can get/set > hvm > > Did you forgot to push or 3.1-testing commits waits for internal testing? > > Cheers_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel