xen.org
2010-Nov-29 22:41 UTC
[Xen-devel] [xen-4.0-testing bisection] complete build-i386-xcpkern
branch xen-4.0-testing
xen branch xen-4.0-testing
job build-i386-xcpkern
test kernel-build
Tree: http://hg.uk.xensource.com/xen-4.0-testing.hg
*** Found and reproduced problem changeset ***
Bug is in tree: http://hg.uk.xensource.com/xen-4.0-testing.hg
Bug introduced: 2901cbe2eccc
Bug not present: b6d75c255bf6
changeset: 21389:2901cbe2eccc
user: Keir Fraser <keir@xen.org>
date: Mon Nov 29 14:46:01 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>
xen-unstable changeset: 22448:5cd9612db2bb
xen-unstable date: Mon Nov 29 14:34:32 2010 +0000
For bisection revision-tuple graph see:
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-4.0-testing.build-i386-xcpkern.kernel-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Found failure, as expected, in flight 2860
Host specification list: host=gall-mite
Searching for basis pass: 2780.
(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-4.0-testing.hg
Latest 465c81b07700
Basis pass b6d75c255bf6
Generating revisions with ./adhoc-revtuple-generator
http://hg.uk.xensource.com/xen-4.0-testing.hg#b6d75c255bf6-465c81b07700
pulling from http://hg.uk.xensource.com/xen-4.0-testing.hg
searching for changes
no changes found
pulling from http://hg.uk.xensource.com/xen-4.0-testing.hg
searching for changes
no changes found
Loaded 1001 nodes in revision graph
Searching for test results:
2868 fail 2901cbe2eccc
2870 fail 2901cbe2eccc
2780 pass b6d75c255bf6
2860 fail 465c81b07700
2865 fail 465c81b07700
2770 pass b6d75c255bf6
Searching for interesting versions
0 revisions at b6d75c255bf6
No revisions left to test, checking graph state.
*** Found and reproduced problem changeset ***
Bug is in tree: http://hg.uk.xensource.com/xen-4.0-testing.hg
Bug introduced: 2901cbe2eccc
Bug not present: b6d75c255bf6
changeset: 21389:2901cbe2eccc
user: Keir Fraser <keir@xen.org>
date: Mon Nov 29 14:46:01 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>
xen-unstable changeset: 22448:5cd9612db2bb
xen-unstable date: Mon Nov 29 14:34:32 2010 +0000
Revision graph left in
/home/xc_osstest/results/bisect.xen-4.0-testing.build-i386-xcpkern.kernel-build.{dot,ps,png,html}.
----------------------------------------
2870: ALL FAIL
flight 2870 xen-4.0-testing real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/2870/
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 21389:2901cbe2eccc
------------------------------------------------------------
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