flight 21288 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/21288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail REGR. vs. 21268
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 21268
test-amd64-amd64-xl-winxpsp3 7 windows-install fail REGR. vs. 21268
test-amd64-amd64-xl-win7-amd64 7 windows-install fail REGR. vs. 21268
test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. vs. 21268
test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 21268
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass
test-armhf-armhf-xl 5 xen-boot fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
version targeted for testing:
xen 41a0cc9e26160a89245c9ba3233e3f70bf9cd4b4
baseline version:
xen 8f5a051507537aa01995dd0a97a50d1c96fcc2b4
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Jun Nakajima <jun.nakajima@intel.com>
Keir Fraser <keir@xen.org>
Matthew Daley <mattjd@gmail.com>
Yang Zhang <yang.z.zhang@Intel.com>
------------------------------------------------------------
jobs:
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 fail
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-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-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-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 pass
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-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 woking.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 41a0cc9e26160a89245c9ba3233e3f70bf9cd4b4
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Oct 29 09:57:14 2013 +0100
fix locking in cpu_disable_scheduler()
So commit eedd6039 ("scheduler: adjust internal locking
interface")
uncovered - by now using proper spin lock constructs - a bug after all:
When bringing down a CPU, cpu_disable_scheduler() gets called with
interrupts disabled, and hence the use of vcpu_schedule_lock_irq() was
never really correct (i.e. the caller ended up with interrupts enabled
despite having disabled them explicitly).
Fixing this however surfaced another problem: The call path
vcpu_migrate() -> evtchn_move_pirqs() wants to acquire the event lock,
which however is a non-IRQ-safe once, and hence check_lock()
doesn''t
like this lock to be acquired when interrupts are already off. As
we''re
in stop-machine context here, getting things wrong wrt interrupt state
management during lock acquire/release is out of question though, so
the simple solution to this appears to be to just suppress spin lock
debugging for the period of time while the stop machine callback gets
run.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
commit c9efe34c119418a5ac776e5d91aeefcce4576518
Author: Yang Zhang <yang.z.zhang@Intel.com>
Date: Tue Oct 29 09:55:23 2013 +0100
VMX: Eliminate cr3 store/load vmexit when UG enabled
With the feature of unrestricted guest, Xen should not cause
vmexits for cr3 accesses in non-paging mode.
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: Jun Nakajima <jun.nakajima@intel.com>
commit 2cd1f418feb215c379b6737576b53bba6f70c1a6
Author: Matthew Daley <mattjd@gmail.com>
Date: Sun Oct 27 19:49:14 2013 +1300
xl: don''t emit misleading daemon pid message
After creating a domain, xl forks off a process to handle domain events
(shutdown, disk eject, ...). It prints out the pid of the process
created by the fork to stdout. However, the newly forked process soon
after calls daemon(), which itself forks once more (and exit()s the
original process). This means that the pid printed out is not the pid of
the actual process which remains in the background after all is said and
done, instead it is the pid of the transient process that exists between
xl''s fork() and the fork''d process''s daemon()
call.
We could resolve this by printing the correct pid, ie. by open-coding
daemon() (we already do most of the heavy lifting it does ourselves by
fiddling with the standard fds). However, since no-one seems to be
complaining about the misleading message to begin with, and since it
seems like a pointless message anyway, just remove it outright instead.
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
commit 35e874b1d5d56dd2098313364b879c637fa56844
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Fri Oct 25 08:47:35 2013 +0100
libxenstore: Use PTHREAD_STACK_MIN
The existing value of 16K is smaller than the arm64 minimum stack size,
which
is 128K. PTHREAD_STACK_MIN appears to be standard
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstacksize.html
Consindered setting a lower bound but the stack requirements of the watcher
thread are pretty minimal (tens of bytes from the looks of it) and unlikely
to
blow PTHREAD_STACK_MIN on any useful platform.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
commit dc19afbad9319b00474951d4218a37c072a6570b
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Fri Oct 25 08:47:24 2013 +0100
libxl: remove spurious newline from LOG() message
The macro already includes this.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
commit e6564c634863680f6541e07ce2f77f17d45ce52e
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Mon Oct 28 11:30:35 2013 +0000
libelf: improve errors in elf_xen_note_check()
I recently debugged an isolated failure to boot, with no information other
than the logs.
The "Will only load images built for the generic loader or Linux
images"
string was missing a newline, leading to the subsequent error being appended
to this line, rather than having its own line with correctly identified
function.
Furthermore, error messages which state "param containing $FOO is not
$BAR" is
fairly useless for debugging without identifying which bad $FOO caused the
failure.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(qemu changes not included)
>>> On 30.10.13 at 01:30, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 21288 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/21288/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail REGR. vs. 21268 > test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 21268 > test-amd64-amd64-xl-winxpsp3 7 windows-install fail REGR. vs. 21268 > test-amd64-amd64-xl-win7-amd64 7 windows-install fail REGR. vs. 21268 > test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. vs. 21268 > test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 21268All but the first one are due to the guests triple faulting while booting. While - unless otherwise confirmed - I''d like to wait for bisector results here, the prime suspect appears to be c9efe34c ("VMX: Eliminate cr3 store/load vmexit when UG enabled") - any thoughts? Did you perhaps not test this on a system without UG support? Jan
Jan Beulich wrote on 2013-10-30:>>>> On 30.10.13 at 01:30, xen.org <ian.jackson@eu.citrix.com> wrote: >> flight 21288 xen-unstable real [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/21288/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, including tests which >> could not be run: >> test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail REGR. >> vs. 21268 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install >> fail REGR. vs. 21268 test-amd64-amd64-xl-winxpsp3 7 windows-install >> fail REGR. vs. 21268 test-amd64-amd64-xl-win7-amd64 7 >> windows-install fail REGR. vs. 21268 >> test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. >> vs. 21268 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install >> fail REGR. > vs. 21268 > > All but the first one are due to the guests triple faulting while > booting. While - unless otherwise confirmed - I''d like to wait for > bisector results here, the prime suspect appears to be c9efe34c > ("VMX: Eliminate cr3 store/load vmexit when UG enabled") - any > thoughts? Did you perhaps not test this on a system without UG support?Yes, the previous patch will cause the guest boot fail on non-UG platform. The following patch is able to fix it. But going deep into the code, I am thinking whether the current logic that set hw_cr[3] and guest_cr[3] from GUEST_CR3 is really necessary. Especially, each VMexit does the same thing. diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 502caa3..702b493 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2411,7 +2411,8 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) if ( paging_mode_hap(v->domain) ) { __vmread(GUEST_CR3, &v->arch.hvm_vcpu.hw_cr[3]); - v->arch.hvm_vcpu.guest_cr[3] = v->arch.hvm_vcpu.hw_cr[3]; + if ( vmx_unrestricted_guest(v) || hvm_paging_enabled(v) ) + v->arch.hvm_vcpu.guest_cr[3] = v->arch.hvm_vcpu.hw_cr[3]; } __vmread(VM_EXIT_REASON, &exit_reason);> > JanBest regards, Yang
>>> On 30.10.13 at 15:53, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote: > Jan Beulich wrote on 2013-10-30: >>>>> On 30.10.13 at 01:30, xen.org <ian.jackson@eu.citrix.com> wrote: >>> flight 21288 xen-unstable real [real] >>> http://www.chiark.greenend.org.uk/~xensrcts/logs/21288/ >>> >>> Regressions :-( >>> >>> Tests which did not succeed and are blocking, including tests which >>> could not be run: >>> test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail REGR. >>> vs. 21268 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install >>> fail REGR. vs. 21268 test-amd64-amd64-xl-winxpsp3 7 windows-install >>> fail REGR. vs. 21268 test-amd64-amd64-xl-win7-amd64 7 >>> windows-install fail REGR. vs. 21268 >>> test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. >>> vs. 21268 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install >>> fail REGR. >> vs. 21268 >> >> All but the first one are due to the guests triple faulting while >> booting. While - unless otherwise confirmed - I''d like to wait for >> bisector results here, the prime suspect appears to be c9efe34c >> ("VMX: Eliminate cr3 store/load vmexit when UG enabled") - any >> thoughts? Did you perhaps not test this on a system without UG support? > > Yes, the previous patch will cause the guest boot fail on non-UG platform. > The following patch is able to fix it. > But going deep into the code, I am thinking whether the current logic that > set hw_cr[3] and guest_cr[3] from GUEST_CR3 is really necessary. Especially, > each VMexit does the same thing.Feel free to clean this up.> --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -2411,7 +2411,8 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) > if ( paging_mode_hap(v->domain) ) > { > __vmread(GUEST_CR3, &v->arch.hvm_vcpu.hw_cr[3]); > - v->arch.hvm_vcpu.guest_cr[3] = v->arch.hvm_vcpu.hw_cr[3]; > + if ( vmx_unrestricted_guest(v) || hvm_paging_enabled(v) ) > + v->arch.hvm_vcpu.guest_cr[3] = v->arch.hvm_vcpu.hw_cr[3]; > } > > __vmread(VM_EXIT_REASON, &exit_reason);We''ll need a proper patch in any event. As I''m going to be out of the office for the rest of the week, I guess I''ll revert the patch for now, and you then better send another rev of it with the above change included. Jan
Jan Beulich wrote on 2013-10-30:>>>> On 30.10.13 at 15:53, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote: >> Jan Beulich wrote on 2013-10-30: >>>>>> On 30.10.13 at 01:30, xen.org <ian.jackson@eu.citrix.com> wrote: >>>> flight 21288 xen-unstable real [real] >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/21288/ >>>> >>>> Regressions :-( >>>> >>>> Tests which did not succeed and are blocking, including tests >>>> which could not be run: >>>> test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail REGR. >>>> vs. 21268 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install >>>> fail REGR. vs. 21268 test-amd64-amd64-xl-winxpsp3 7 windows-install >>>> fail REGR. vs. 21268 test-amd64-amd64-xl-win7-amd64 7 >>>> windows-install fail REGR. vs. 21268 >>>> test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. >>>> vs. 21268 test-amd64-i386-xl-qemut-win7-amd64 7 windows-install >>>> fail REGR. >>> vs. 21268 >>> >>> All but the first one are due to the guests triple faulting while >>> booting. While - unless otherwise confirmed - I''d like to wait for >>> bisector results here, the prime suspect appears to be c9efe34c >>> ("VMX: Eliminate cr3 store/load vmexit when UG enabled") - any >>> thoughts? Did you perhaps not test this on a system without UG support? >> >> Yes, the previous patch will cause the guest boot fail on non-UG platform. >> The following patch is able to fix it. >> But going deep into the code, I am thinking whether the current >> logic that set hw_cr[3] and guest_cr[3] from GUEST_CR3 is really necessary. >> Especially, each VMexit does the same thing. > > Feel free to clean this up.Just looking into the code. The current logic is necessary since there are lots of codes depend on them, so cannot remove them simply. I will rebase the patch with the fixing included.> >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -2411,7 +2411,8 @@ void vmx_vmexit_handler(struct cpu_user_regs > *regs) >> if ( paging_mode_hap(v->domain) ) >> { >> __vmread(GUEST_CR3, &v->arch.hvm_vcpu.hw_cr[3]); >> - v->arch.hvm_vcpu.guest_cr[3] = v->arch.hvm_vcpu.hw_cr[3]; >> + if ( vmx_unrestricted_guest(v) || hvm_paging_enabled(v) ) >> + v->arch.hvm_vcpu.guest_cr[3] >> + v->arch.hvm_vcpu.hw_cr[3]; >> } >> >> __vmread(VM_EXIT_REASON, &exit_reason); > > We''ll need a proper patch in any event. As I''m going to be out of the > office for the rest of the week, I guess I''ll revert the patch for > now, and you then better send another rev of it with the above change included. > > JanBest regards, Yang