>>> 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
|
Home