|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-unstable bisection] complete build-i386-xcpkern
>>> On 30.11.10 at 08:12, Keir Fraser <keir@xxxxxxx> wrote: > Looks like cause of failure was in the kernel build. So this bisection > result doesn't look very likely? If it failed in a guest running on the new hypervisor, this might still indicate a problem with the change, but the log doesn't provide any helpful detail (it's the "hg clone" of a 2.6.27 tree that causes a Python exception, but that can't be connected to the c/s in question without further information). Jan > On 29/11/2010 23:25, "xen.org" <ian.jackson@xxxxxxxxxxxxx> wrote: > >> branch xen-unstable >> xen branch xen-unstable >> job build-i386-xcpkern >> test kernel-build >> >> Tree: http://hg.uk.xensource.com/xen-unstable.hg >> >> *** Found and reproduced problem changeset *** >> >> Bug is in tree: http://hg.uk.xensource.com/xen-unstable.hg >> Bug introduced: 5cd9612db2bb >> Bug not present: aba70e59a90d >> >> >> changeset: 22448:5cd9612db2bb >> user: Keir Fraser <keir@xxxxxxx> >> date: Mon Nov 29 14:34:32 2010 +0000 >> >> x86-64: don't crash Xen upon direct pv guest access to GDT/LDT mapping >> area >> >> handle_gdt_ldt_mapping_fault() is intended to deal with indirect >> accesses (i.e. those caused by descriptor loads) to the GDT/LDT >> mapping area only. While for 32-bit segment limits indeed prevent the >> function being entered for direct accesses (i.e. a #GP fault will be >> raised even before the address translation gets done, on 64-bit even >> user mode accesses would lead to control reaching the BUG_ON() at the >> beginning of that function. >> >> Fortunately the fix is simple: Since the guest kernel runs in ring 3, >> any guest direct access will have the "user mode" bit set, whereas >> descriptor loads always do the translations to access the actual >> descriptors as kernel mode ones. >> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> >> >> Further, relax the BUG_ON() in handle_gdt_ldt_mapping_fault() to a >> check-and-bail. This avoids any problems in future, if we don't >> execute x86_64 guest kernels in ring 3 (e.g., because we use a >> lightweight HVM container). >> >> Signed-off-by: Keir Fraser <keir@xxxxxxx> >> >> >> For bisection revision-tuple graph see: >> >> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build- >> >> i386-xcpkern.kernel-build.html >> Revision IDs in each graph node refer, respectively, to the Trees above. >> >> ---------------------------------------- >> Found failure, as expected, in flight 2861 >> Host specification list: host=gall-mite >> Searching for basis pass: 2856. >> (tree in basispass but not in latest: >> http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27.hg) >> (tree in basispass but not in latest: >> http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27.pq.hg) >> Tree: http://hg.uk.xensource.com/xen-unstable.hg >> Latest 3afb5ecbf69f >> Basis pass aba70e59a90d >> Generating revisions with ./adhoc-revtuple-generator >> http://hg.uk.xensource.com/xen-unstable.hg#aba70e59a90d-3afb5ecbf69f >> pulling from http://hg.uk.xensource.com/xen-unstable.hg >> searching for changes >> no changes found >> pulling from http://hg.uk.xensource.com/xen-unstable.hg >> searching for changes >> no changes found >> Loaded 1000 nodes in revision graph >> Searching for test results: >> 2853 pass aba70e59a90d >> 2854 pass aba70e59a90d >> 2871 fail 3afb5ecbf69f >> 2872 fail 5cd9612db2bb >> 2873 fail 5cd9612db2bb >> 2855 pass aba70e59a90d >> 2849 pass aba70e59a90d >> 2861 fail 3afb5ecbf69f >> 2850 pass irrelevant >> 2856 pass aba70e59a90d >> Searching for interesting versions >> 0 revisions at aba70e59a90d >> No revisions left to test, checking graph state. >> >> *** Found and reproduced problem changeset *** >> >> Bug is in tree: http://hg.uk.xensource.com/xen-unstable.hg >> Bug introduced: 5cd9612db2bb >> Bug not present: aba70e59a90d >> >> >> changeset: 22448:5cd9612db2bb >> user: Keir Fraser <keir@xxxxxxx> >> date: Mon Nov 29 14:34:32 2010 +0000 >> >> x86-64: don't crash Xen upon direct pv guest access to GDT/LDT mapping >> area >> >> handle_gdt_ldt_mapping_fault() is intended to deal with indirect >> accesses (i.e. those caused by descriptor loads) to the GDT/LDT >> mapping area only. While for 32-bit segment limits indeed prevent the >> function being entered for direct accesses (i.e. a #GP fault will be >> raised even before the address translation gets done, on 64-bit even >> user mode accesses would lead to control reaching the BUG_ON() at the >> beginning of that function. >> >> Fortunately the fix is simple: Since the guest kernel runs in ring 3, >> any guest direct access will have the "user mode" bit set, whereas >> descriptor loads always do the translations to access the actual >> descriptors as kernel mode ones. >> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> >> >> Further, relax the BUG_ON() in handle_gdt_ldt_mapping_fault() to a >> check-and-bail. This avoids any problems in future, if we don't >> execute x86_64 guest kernels in ring 3 (e.g., because we use a >> lightweight HVM container). >> >> Signed-off-by: Keir Fraser <keir@xxxxxxx> >> >> Revision graph left in >> /home/xc_osstest/results/bisect.xen-unstable.build-i386-xcpkern.kernel-build.{ >> dot,ps,png,html}. >> ---------------------------------------- >> 2873: ALL FAIL >> >> flight 2873 xen-unstable real-bisect [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/2873/ >> >> tests which did not succeed: >> build-i386-xcpkern 4 kernel-build fail >> >> version targeted for testing: >> baseline version: >> >> jobs: >> build-i386-xcpkern fail >> >> > ------------------------------------------------------------------------------> > - >> build-i386-xcpkern: >> 1 hosts-allocate pass >> 2 host-install(2) pass >> 3 host-build-prep pass >> 4 kernel-build fail >> xen 22448:5cd9612db2bb >> >> ------------------------------------------------------------ >> 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 >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxxxxxxxx >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |