Re: [Xen-devel] [xen-unstable bisection] complete build-i386-xcpkern

[Keir Fraser <keir@xxxxxxx>]

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