| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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@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
|
|
|
| |
|
Home