xen.org
2010-Nov-29 23:25 UTC
[Xen-devel] [xen-unstable bisection] complete build-i386-xcpkern
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@xen.org>
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@novell.com>
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@xen.org>
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@xen.org>
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@novell.com>
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@xen.org>
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@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2010-Nov-30 07:12 UTC
Re: [Xen-devel] [xen-unstable bisection] complete build-i386-xcpkern
Looks like cause of failure was in the kernel build. So this bisection result doesn''t look very likely? -- Keir On 29/11/2010 23:25, "xen.org" <ian.jackson@eu.citrix.com> 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@xen.org> > 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@novell.com> > > 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@xen.org> > > > 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@xen.org> > 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@novell.com> > > 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@xen.org> > > 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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Nov-30 08:19 UTC
Re: [Xen-devel] [xen-unstable bisection] complete build-i386-xcpkern
>>> On 30.11.10 at 08:12, Keir Fraser <keir@xen.org> 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@eu.citrix.com> 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@xen.org> >> 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@novell.com> >> >> 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@xen.org> >> >> >> 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@xen.org> >> 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@novell.com> >> >> 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@xen.org> >> >> 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@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
Ian Jackson
2010-Nov-30 11:18 UTC
[Xen-devel] Re: [xen-unstable bisection] complete build-i386-xcpkern
Ian Jackson writes ("[xen-unstable bisection] complete
build-i386-xcpkern"):> 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 ***
...> changeset: 22448:5cd9612db2bb
> user: Keir Fraser <keir@xen.org>
> date: Mon Nov 29 14:34:32 2010 +0000
This is a lie. The real problem was that the internal hg server was
down.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel