IPF-Xen3.3-RC1 testing is blocked by a compiling issue of remote-qemu

IPF-Xen3.3-RC1 testing is blocked by a compiling issue of remote-qemu

[Zhang, Jingke]

Hi all,
    I am trying to build Xen3.3.0-RC1 on IPF with remote-qemu, but met
an error:
    ================
make[4]: Entering directory
`/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/ioemu-r
emote/i386-dm'
gcc -I. -I..
-I/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/ioemu-
dir/target-i386
-I/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/ioemu-
dir -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE
-I/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/ioemu-
dir/tcg
-I/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/ioemu-
dir/tcg/ia64
-I/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/ioemu-
dir/fpu  -DHAS_AUDIO -DHAS_AUDIO
-I/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/..//to
ols/libxc
-I/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/..//to
ols/xenstore
-I/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/..//to
ols/include
-I/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/..//to
ols/blktap/lib -Wall -O2 -g -fno-strict-aliasing -O2
-fomit-frame-pointer -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement
-D__XEN_TOOLS__  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -Wno-unused
-Wno-declaration-after-statement -Wno-pointer-sign  -DCONFIG_PASSTHROUGH
-I../hw -mno-sdata   -DUSE_SSE2=1 -msse2 -Wno-unused
-Wno-declaration-after-statement -Wno-pointer-sign  -DCONFIG_PASSTHROUGH
-c -o vl.o
/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/ioemu-di
r/vl.c
cc1: error: unrecognized command line option "-msse2"
make[4]: *** [vl.o] Error 1
make[4]: Leaving directory
`/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/ioemu-r
emote/i386-dm'
make[3]: *** [subdir-i386-dm] Error 2
make[3]: Leaving directory
`/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools/ioemu-r
emote'
make[2]: *** [subdir-install-ioemu-dir] Error 2
make[2]: Leaving directory
`/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory
`/home/build/nightly/builds_xen_ia64_unstable/xen3.3.0-rc1/tools'
make: *** [install-tools] Error 2
    ================

    This error should be related to the remote-qemu building (we have
disabled stub-domain compiling). If I use "CONFIG_QEMU=ioemu make -j3"
command to make, it can work. Does anyone also meet this issue? If so,
we need to fix this for IPF in Xen3.3 release. Thanks!


Thanks,
Zhang Jingke

Re: IPF-Xen3.3-RC1 testing is blocked by a compiling issue of remote-qemu

[Isaku Yamahata]

On Thu, Jul 31, 2008 at 10:33:25AM +0800, Zhang, Jingke wrote:

>     This error should be related to the remote-qemu building (we have
> disabled stub-domain compiling). If I use "CONFIG_QEMU=ioemu make -j3"
> command to make, it can work. Does anyone also meet this issue? If so,
> we need to fix this for IPF in Xen3.3 release. Thanks!

Hi, thank you for reporting.
As long as I know, ioemu-remote and stub domain on ia64 haven't been
addressed yet. And yes, I agree with you that those should be fixed.
Are there any other issues on ia64 to be addressed for Xen 3.3 release?
It would be desirable to exercise well dma heap logic (18157:445681d122c0
and 18158:b25fa9df7375), I'm not sure it's possible before the release.

My top priority at this moment is the panic which Inakoshi-san
reported recently that is the reason why I haven't requested Keir to
pull the ia64 changes even after 3.3-rc1 had been released.

thanks,
-- 
yamahata

RE: [Xen-ia64-devel] IPF-Xen3.3-RC1 testing is blocked by a compiling issue of remote-qemu

[Zhang, Jingke]

Isaku Yamahata wrote:
> On Thu, Jul 31, 2008 at 10:33:25AM +0800, Zhang, Jingke wrote:
> 
>>     This error should be related to the remote-qemu building (we have
>> disabled stub-domain compiling). If I use "CONFIG_QEMU=ioemu make
>> -j3" command to make, it can work. Does anyone also meet this issue?
>> If so, we need to fix this for IPF in Xen3.3 release. Thanks!
> 
> Hi, thank you for reporting.
> As long as I know, ioemu-remote and stub domain on ia64 haven't been
> addressed yet. And yes, I agree with you that those should be fixed.
> Are there any other issues on ia64 to be addressed for Xen 3.3
> release? It would be desirable to exercise well dma heap logic
> (18157:445681d122c0 and 18158:b25fa9df7375), I'm not sure it's
> possible before the release. 
> 

Hi Isaku,
    Thank you for your information on IPF stub-domain and remote-qemu.
For the Xen3.3 release test on IPF, we plan to test remote-ioemu since
it can work on x86 side (we do not have plan to enable stub-domain for
testing currently). Besides those two, we did not find any old issue
left specially for IPF in this 3.3 release, for IPF is stable by our
nightly testing.  :-)
    To the new dma heap logic changes, I will do a regression testing to
see if IPF has new issues. Thanks!
     

> My top priority at this moment is the panic which Inakoshi-san
> reported recently that is the reason why I haven't requested Keir to
> pull the ia64 changes even after 3.3-rc1 had been released.
> 
> thanks,



Thanks,
Zhang Jingke

Re: Re: [Xen-ia64-devel] IPF-Xen3.3-RC1 testing is blocked by a compiling issue of remote-qemu

[Keir Fraser]

On 31/7/08 04:12, "Isaku Yamahata" <yamahata@valinux.co.jp> wrote:

> Hi, thank you for reporting.
> As long as I know, ioemu-remote and stub domain on ia64 haven't been
> addressed yet. And yes, I agree with you that those should be fixed.
> Are there any other issues on ia64 to be addressed for Xen 3.3 release?
> It would be desirable to exercise well dma heap logic (18157:445681d122c0
> and 18158:b25fa9df7375), I'm not sure it's possible before the release.

August 15th is a fairly firm date for final release of 3.3.0. For stubdomain
and ioemu-remote -- both are optional build items for this release (although
default to on) so a simple and reasonable fix for ia64 would be to disable
these items in the build. You can then work on getting them to work for ia64
(if it makes sense to do so) in 3.4 branch.

 -- Keir

Re: [Xen-devel] Re: IPF-Xen3.3-RC1 testing is blocked by a compiling issue of remote-qemu

[Samuel Thibault]

Keir Fraser, le Thu 31 Jul 2008 08:10:19 +0100, a écrit :
> For stubdomain and ioemu-remote -- both are optional build items for
> this release (although default to on) so a simple and reasonable fix
> for ia64 would be to disable these items in the build.

That should already be the case for stubdom.

Samuel

Re: [Xen-ia64-devel] IPF-Xen3.3-RC1 testing is blocked by a compiling issue of remote-qemu

[Samuel Thibault]

Isaku Yamahata, le Thu 31 Jul 2008 12:12:22 +0900, a écrit :
> As long as I know, ioemu-remote and stub domain on ia64 haven't been
> addressed yet.

ioemu-remote should be mostly about fixing bugs.  Stub domain is about
implementing memory management in MiniOS.

Samuel

RE: Re: [Xen-ia64-devel] IPF-Xen3.3-RC1 testing isblocked by a compiling issue of remote-qemu

[Li, Haicheng]

Keir Fraser wrote:
> August 15th is a fairly firm date for final release of 3.3.0. For
> stubdomain and ioemu-remote -- both are optional build items for this
> release (although default to on) so a simple and reasonable fix for

Keir, is ioemu-remote also an optional feature for x86? If it is
optional, could we use old qemu to do RC testing if ioemu-remote still
has block issue?

> ia64 would be to disable these items in the build. You can then work
> on getting them to work for ia64 (if it makes sense to do so) in 3.4
> branch. 
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



-- haicheng

Re: Re: [Xen-ia64-devel] IPF-Xen3.3-RC1 testing isblocked by a compiling issue of remote-qemu

[Keir Fraser]

On 4/8/08 07:12, "Li, Haicheng" <haicheng.li@intel.com> wrote:

> Keir Fraser wrote:
>> August 15th is a fairly firm date for final release of 3.3.0. For
>> stubdomain and ioemu-remote -- both are optional build items for this
>> release (although default to on) so a simple and reasonable fix for
> 
> Keir, is ioemu-remote also an optional feature for x86? If it is
> optional, could we use old qemu to do RC testing if ioemu-remote still
> has block issue?

Yes, that's the intention. ioemu-remote will continue to be the default for
x86 though.

 -- Keir