3.1.x and 3.2.x releases

3.1.x and 3.2.x releases

[Keir Fraser]

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

RE: 3.1.x and 3.2.x releases

[Dan Magenheimer]

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
>

Re: 3.1.x and 3.2.x releases

[Keir Fraser]

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

RE: 3.1.x and 3.2.x releases

[Dan Magenheimer]

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
>

Re: 3.1.x and 3.2.x releases

[Keir Fraser]

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

RE: 3.1.x and 3.2.x releases

[Dan Magenheimer]

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
>

Re: 3.1.x and 3.2.x releases

[Keir Fraser]

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

Re: 3.1.x and 3.2.x releases

[Keir Fraser]

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

RE: 3.1.x and 3.2.x releases

[Dan Magenheimer]

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

Re: 3.1.x and 3.2.x releases

[John Levon]

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

RE: 3.1.x and 3.2.x releases

[You, Yongkang]

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

Re: 3.1.x and 3.2.x releases

[John Levon]

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

I'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

Re: 3.1.x and 3.2.x releases

[S.Çağlar Onur]

[-- Attachment #1.1: Type: text/plain, Size: 3710 bytes --]

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!

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: 3.1.x and 3.2.x releases

[Keir Fraser]

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

Re: 3.1.x and 3.2.x releases

[S.Çağlar Onur]

[-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --]

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!

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: 3.1.x and 3.2.x releases

[Keir Fraser]

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

Re: 3.1.x and 3.2.x releases

[John Levon]

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

Re: 3.1.x and 3.2.x releases

[Keir Fraser]

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

Re: 3.1.x and 3.2.x releases

[Ryan Scott]

[-- Attachment #1.1: Type: text/plain, Size: 1652 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 2533 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: 3.1.x and 3.2.x releases

[Daniel P. Berrange]

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

Re: 3.1.x and 3.2.x releases

[Keir Fraser]

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

Re: 3.1.x and 3.2.x releases

[S.Çağlar Onur]

[-- Attachment #1.1: Type: text/plain, Size: 1036 bytes --]

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!

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: 3.1.x and 3.2.x releases

[Keir Fraser]

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

Re: 3.1.x and 3.2.x releases

[S.Çağlar Onur]

[-- Attachment #1.1: Type: text/plain, Size: 1163 bytes --]

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!

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel