[xen-4.4-testing test] 25979: regressions - FAIL

[xen-4.4-testing test] 25979: regressions - FAIL

[xen.org]

flight 25979 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 25794

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-saverestore           fail pass in 25970

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl          10 migrate-support-check        fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop         fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop              fail never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop                   fail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop              fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop             fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop             fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check        fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop                   fail   never pass

version targeted for testing:
 xen                  139a62e98161051e7687d6c356d9a9b92a8801a3
baseline version:
 xen                  03eb5134056d61167e6781eecf7e570b491bda73

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <julien.grall@linaro.org>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64-xend                                             pass    
 build-i386-xend                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 139a62e98161051e7687d6c356d9a9b92a8801a3
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Apr 23 16:32:45 2014 +0100

    xen/arm: vgic: Check rank in GICD_ICFGR* emulation before locking
    
    The function vgic_irq_rank may return NULL is the IRQ is not in range handled
    by the guest. This will result to derefence a NULL pointer which will crash
    Xen.
    
    I've checked the rest of the emulation and this is only place where the lock
    is taken before the rank is checked.
    
    This is CVE-2014-2986 / XSA-94.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Reported-by: Thomas Leonard <talex5@gmail.com>
    Reviewed-by: Jan Beulich <JBeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit fc070bcb683e6251a4c18b144ca7d869fc2f6467
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Apr 23 16:25:21 2014 +0200

    xen: x86 & generic: change to __builtin_prefetch()
    
    Quoting Andi Kleen in Linux b483570a13be from 2007:
        gcc 3.2+ supports __builtin_prefetch, so it's possible to use it on all
        architectures. Change the generic fallback in linux/prefetch.h to use it
        instead of noping it out. gcc should do the right thing when the
        architecture doesn't support prefetching
    
        Undefine the x86-64 inline assembler version and use the fallback.
    
    ARM wants to use the builtins.
    
    Fix a pair of spelling errors, one of which was from Lucas De Marchi in the
    Linux tree.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Cc: Keir Fraser <keir@xen.org>
    Acked-by: Tim Deegan <tim@xen.org>
    master commit: 630017f420f111e0c0332dbd99df30ebb8fed207
    master date: 2014-04-03 17:15:41 +0100

commit cbd5a0c3fd72983fb7b4b5c689280209f8da218b
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Apr 23 16:24:02 2014 +0200

    x86/mm: fix checks against max_mapped_pfn
    
    This value is an inclusive one, i.e. this fixes an off-by-one in memory
    sharing and an off-by-two in shadow code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Tim Deegan <tim@xen.org>
    master commit: 088ee1d47b65d6bb92de61b404805f4ca92e3240
    master date: 2014-04-03 12:08:43 +0100

commit da8e1586278dffd8510876e6fed8d47c9eba713c
Author: Julien Grall <julien.grall@linaro.org>
Date:   Tue Apr 15 14:06:42 2014 +0100

    xen/arm: Don't let guess access to Debug and Performance Monitor registers
    
    Debug and performance registers are not properly switched by Xen.
    
    Trap them and inject an undefined instruction, except for those registers
    which might be unconditionally accessed which we implement as RAZ/WI.
    
    This is CVE-2014-2915 / XSA-93.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

commit 8f416fc2669769a72783e13072547f8b2d071065
Author: Julien Grall <julien.grall@linaro.org>
Date:   Tue Apr 15 12:45:28 2014 +0100

    xen/arm: Don't expose implementation defined registers (Cp15 c15) to the guest
    
    On Cortex-A15, CP15 c15 contains registers to retrieve data from L1/L2 RAM.
    
    Exposing this registers to guest may result to leak data from Xen and/or
    another guest.
    
    By default trap every registers and inject an undefined instruction.
    
    This is CVE-2014-2915 / XSA-93.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 4642a2146e3d309266f537e7bbf55f5d85249229
Author: Julien Grall <julien.grall@linaro.org>
Date:   Mon Apr 14 20:00:14 2014 +0100

    xen/arm: Trap cache and TCM lockdown registers
    
    Some cp15 c9/c10/c11 encodings are used for:
         - cache control
         - TCM control
         - branch predictor control
    
    All of them are implementation defined. For now inject an undefined exception
    if the guest wants try to access it.
    
    This is CVE-2014-2915 / XSA-93.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 16ef39e797b0ef82449321ff5af7590e17b1b670
Author: Julien Grall <julien.grall@linaro.org>
Date:   Mon Apr 14 20:46:43 2014 +0100

    xen/arm: Upgrade DCISW into DCCISW
    
    A guest is allowed to use invalidate cache by set/way instruction (i.e DCISW)
    without any restriction. As the cache is shared with Xen, the guest invalidate
    an address being in used by Xen. This may lead a Xen crash because the memory
    state is invalid.
    Set the bit HCR.SWIO to upgrade invalidate cache by set/way instruction to an
    invalidate and clean.
    
    This is CVE-2014-2915 / XSA-93.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Reported-by: Thomas Leonard <tal36@cam.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit 9800bfa275b654b20522c1c8e78eba12d4b21e2f
Author: Julien Grall <julien.grall@linaro.org>
Date:   Mon Apr 14 20:37:16 2014 +0100

    xen/arm: Don't let the guest access the coprocessors registers
    
    In Xen we only handle save/restore for coprocessor 10 and 11 (NEON). Other
    coprocessors (0-9, 12-13) are currently exposed to the guest and may lead
    to data shared between guest.
    
    Disable access to all coprocessor except 10 and 11 by setting correctly
    HCTPR.
    
    This is CVE-2014-2915 / XSA-93.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

commit ed13367f161c8e0716f75773c7915df1d0388263
Author: Julien Grall <julien.grall@linaro.org>
Date:   Mon Apr 14 19:01:20 2014 +0100

    xen/arm: Inject an undefined instruction when the coproc/sysreg is not handled
    
    Currently Xen panics if it's unable to handle a coprocessor/sysreg instruction.
    Replace this behavior by inject an undefined instruction to the faulty guest
    and log if Xen is in debug mode.
    
    This is CVE-2014-2915 / XSA-93.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
(qemu changes not included)

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Jan Beulich]

>>> On 25.04.14 at 13:11, <Ian.Jackson@eu.citrix.com> wrote:
> flight 25979 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 25794

This has been failing for the last several runs, yet again without
me being able to see anything suspicious in the logs. The screen
shots of the guest suggest it came mostly up, but may still be
doing something before being fully up. Yet again, just like noted
for one of the -unstable failures recently, the 4th boot of the
guest is suspiciously close to the 7000s timeout...

Jan

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Ian Campbell]

On Fri, 2014-04-25 at 12:34 +0100, Jan Beulich wrote:
> >>> On 25.04.14 at 13:11, <Ian.Jackson@eu.citrix.com> wrote:
> > flight 25979 xen-4.4-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 25794
> 
> This has been failing for the last several runs, yet again without
> me being able to see anything suspicious in the logs. The screen
> shots of the guest suggest it came mostly up, but may still be
> doing something before being fully up. Yet again, just like noted
> for one of the -unstable failures recently, the 4th boot of the
> guest is suspiciously close to the 7000s timeout...

The diff between 25794 and now is:
        139a62e xen/arm: vgic: Check rank in GICD_ICFGR* emulation before locking
        fc070bc xen: x86 & generic: change to __builtin_prefetch()
        cbd5a0c x86/mm: fix checks against max_mapped_pfn
        da8e158 xen/arm: Don't let guess access to Debug and Performance Monitor regist
        8f416fc xen/arm: Don't expose implementation defined registers (Cp15 c15) to th
        4642a21 xen/arm: Trap cache and TCM lockdown registers
        16ef39e xen/arm: Upgrade DCISW into DCCISW
        9800bfa xen/arm: Don't let the guest access the coprocessors registers
        ed13367 xen/arm: Inject an undefined instruction when the coproc/sysreg is not 
        
Most of which is irrelevant to an x86 test. Unless fc070bc (unlikely) or
cbd5a0c (I cannot judge) made windows installs slower?

How long did the fourth boot take in 25794 I wonder?

The other possibility is that this is host specific, and that lake-frog
is just slow compared with other machines. Since osstest is sticky to
hosts on failures all the tests since the initial failure in 25958 have
been on the same host.

Unfortunately my osstest db-fu isn't really up to datamining the history
of this test case on various machines. Ian J is away for a few days,
perhaps he can take a look at this aspect when he gets back?

Ian.

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Jan Beulich]

>>> On 25.04.14 at 13:46, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-04-25 at 12:34 +0100, Jan Beulich wrote:
>> >>> On 25.04.14 at 13:11, <Ian.Jackson@eu.citrix.com> wrote:
>> > flight 25979 xen-4.4-testing real [real]
>> > http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/ 
>> > 
>> > Regressions :-(
>> > 
>> > Tests which did not succeed and are blocking,
>> > including tests which could not be run:
>> >  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 
> 25794
>> 
>> This has been failing for the last several runs, yet again without
>> me being able to see anything suspicious in the logs. The screen
>> shots of the guest suggest it came mostly up, but may still be
>> doing something before being fully up. Yet again, just like noted
>> for one of the -unstable failures recently, the 4th boot of the
>> guest is suspiciously close to the 7000s timeout...
> 
> The diff between 25794 and now is:
>         139a62e xen/arm: vgic: Check rank in GICD_ICFGR* emulation before locking
>         fc070bc xen: x86 & generic: change to __builtin_prefetch()
>         cbd5a0c x86/mm: fix checks against max_mapped_pfn
>         da8e158 xen/arm: Don't let guess access to Debug and Performance Monitor regist
>         8f416fc xen/arm: Don't expose implementation defined registers (Cp15 c15) to th
>         4642a21 xen/arm: Trap cache and TCM lockdown registers
>         16ef39e xen/arm: Upgrade DCISW into DCCISW
>         9800bfa xen/arm: Don't let the guest access the coprocessors registers
>         ed13367 xen/arm: Inject an undefined instruction when the coproc/sysreg is not 
>         
> Most of which is irrelevant to an x86 test. Unless fc070bc (unlikely) or
> cbd5a0c (I cannot judge) made windows installs slower?
> 
> How long did the fourth boot take in 25794 I wonder?

6247s (ran on lace-bug)

> The other possibility is that this is host specific, and that lake-frog
> is just slow compared with other machines. Since osstest is sticky to
> hosts on failures all the tests since the initial failure in 25958 have
> been on the same host.
> 
> Unfortunately my osstest db-fu isn't really up to datamining the history
> of this test case on various machines. Ian J is away for a few days,
> perhaps he can take a look at this aspect when he gets back?

Yes, I think we should wait for him to take a look before becoming
too worried (and I think we're seeing this test routinely fail on
-unstable too).

Jan

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [xen-4.4-testing test] 25979: regressions - FAIL"):
> On 25.04.14 at 13:46, <Ian.Campbell@citrix.com> wrote:
> > How long did the fourth boot take in 25794 I wonder?
> 
> 6247s (ran on lace-bug)

See my other email.  I think this is host-specific.  lace-bug is an
AMD machine.

I think perhaps this is a performance problem with SVM.

Ian.

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Ian Campbell]

On Wed, 2014-04-30 at 16:10 +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.4-testing test] 25979: regressions - FAIL"):
> > On 25.04.14 at 13:46, <Ian.Campbell@citrix.com> wrote:
> > > How long did the fourth boot take in 25794 I wonder?
> > 
> > 6247s (ran on lace-bug)
> 
> See my other email.  I think this is host-specific.  lace-bug is an
> AMD machine.
> 
> I think perhaps this is a performance problem with SVM.

I don't think this is a new thing. I've heard speculation that this may
have been the case since the page-sharing p2m locking changes way back
in 4.2.

I've lost track of who at AMD I should be CCing with this mail -- Jan, I
guess you know?

Ian.

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Ian Campbell]

On Fri, 2014-04-25 at 12:34 +0100, Jan Beulich wrote:
> >>> On 25.04.14 at 13:11, <Ian.Jackson@eu.citrix.com> wrote:
> > flight 25979 xen-4.4-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 25794
> 
> This has been failing for the last several runs, yet again without
> me being able to see anything suspicious in the logs. The screen
> shots of the guest suggest it came mostly up, but may still be
> doing something before being fully up. Yet again, just like noted
> for one of the -unstable failures recently, the 4th boot of the
> guest is suspiciously close to the 7000s timeout...

... it was also run on lake-frog.

Ian.

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Ian Campbell]

On Thu, 2014-05-01 at 11:25 +0100, Ian Campbell wrote:
> On Fri, 2014-04-25 at 12:34 +0100, Jan Beulich wrote:
> > >>> On 25.04.14 at 13:11, <Ian.Jackson@eu.citrix.com> wrote:
> > > flight 25979 xen-4.4-testing real [real]
> > > http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/ 
> > > 
> > > Regressions :-(
> > > 
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 25794
> > 
> > This has been failing for the last several runs, yet again without
> > me being able to see anything suspicious in the logs. The screen
> > shots of the guest suggest it came mostly up, but may still be
> > doing something before being fully up. Yet again, just like noted
> > for one of the -unstable failures recently, the 4th boot of the
> > guest is suspiciously close to the 7000s timeout...
> 
> ... it was also run on lake-frog.

Not sure why I thought this was a new second report... Obviously it
correlates with itself!

Ian.

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Jan Beulich]

>>> On 01.05.14 at 10:26, <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-04-30 at 16:10 +0100, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [Xen-devel] [xen-4.4-testing test] 25979: 
> regressions - FAIL"):
>> > On 25.04.14 at 13:46, <Ian.Campbell@citrix.com> wrote:
>> > > How long did the fourth boot take in 25794 I wonder?
>> > 
>> > 6247s (ran on lace-bug)
>> 
>> See my other email.  I think this is host-specific.  lace-bug is an
>> AMD machine.
>> 
>> I think perhaps this is a performance problem with SVM.
> 
> I don't think this is a new thing. I've heard speculation that this may
> have been the case since the page-sharing p2m locking changes way back
> in 4.2.
> 
> I've lost track of who at AMD I should be CCing with this mail -- Jan, I
> guess you know?

SVM maintainers - can one of you please take looking into this as
an action item?

Thanks, Jan

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Aravind Gopalakrishnan]

On 5/2/2014 4:38 AM, Jan Beulich wrote:
>>
>>> See my other email.  I think this is host-specific.  lace-bug is an
>>> AMD machine.
>>>
>>> I think perhaps this is a performance problem with SVM.
>> I don't think this is a new thing. I've heard speculation that this may
>> have been the case since the page-sharing p2m locking changes way back
>> in 4.2.
>>
>> I've lost track of who at AMD I should be CCing with this mail -- Jan, I
>> guess you know?
> SVM maintainers - can one of you please take looking into this as
> an action item?
>
>

Yes, I'll look into this.
I've got a

cpu family	: 16
model		: 9
stepping	: 1

Will need winxpsp3 image though.

Anyway,
Will keep you guys posted.

-Aravind.

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Aravind Gopalakrishnan]

On 5/2/2014 11:20 AM, Aravind Gopalakrishnan wrote:
> On 5/2/2014 4:38 AM, Jan Beulich wrote:
>>>
>>>> See my other email.  I think this is host-specific.  lace-bug is an
>>>> AMD machine.
>>>>
>>>> I think perhaps this is a performance problem with SVM.
>>> I don't think this is a new thing. I've heard speculation that this may
>>> have been the case since the page-sharing p2m locking changes way back
>>> in 4.2.
>>>
>>> I've lost track of who at AMD I should be CCing with this mail -- 
>>> Jan, I
>>> guess you know?
>> SVM maintainers - can one of you please take looking into this as
>> an action item?
>>
>>
>
> Yes, I'll look into this.
> I've got a
>
> cpu family    : 16
> model        : 9
> stepping    : 1
>
> Will need winxpsp3 image though.
>
> Anyway,
> Will keep you guys posted.
>

Hi,
Sorry for lack of activity as I have not been able dedicate much time on 
this issue last week.

I did try booting a winXpSp3 guest, and it came up fine for me. I am 
working towards setting this up as a continuous test now as the logs 
indicated it was stalling on 4th boot..

Anyway, these links don't seem to work anymore-
1. 
http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/test-amd64-amd64-xl-qemut-winxpsp3/info.html
2. 
http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/test-amd64-amd64-xl-qemut-winxpsp3/

basically all logs for test '25979' don't exist.(It could help me verify 
my set up..)

Something went wrong? Or I am looking at the wrong place?

Thanks,
-Aravind.

Re: [xen-4.4-testing test] 25979: regressions - FAIL

[Jan Beulich]

>>> On 20.05.14 at 22:47, <aravind.gopalakrishnan@amd.com> wrote:
> Anyway, these links don't seem to work anymore-
> 1. 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/test-amd64-amd64-xl-qemut- 
> winxpsp3/info.html
> 2. 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/25979/test-amd64-amd64-xl-qemut- 
> winxpsp3/
> 
> basically all logs for test '25979' don't exist.(It could help me verify 
> my set up..)
> 
> Something went wrong? Or I am looking at the wrong place?

No - old logs get purged after a while.

Jan