* [xen-4.6-testing test] 102519: regressions - FAIL
@ 2016-11-23 4:11 osstest service owner
2016-11-23 9:43 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: osstest service owner @ 2016-11-23 4:11 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 102519 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102519/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 101938
test-xtf-amd64-amd64-3 29 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 101938
test-xtf-amd64-amd64-3 40 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 101938
test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 101938
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 101938
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail like 101924
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 101924
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 101938
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 101938
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 101938
test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 101938
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101938
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101938
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 101938
test-armhf-armhf-xl-rtds 11 guest-start fail like 101938
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
version targeted for testing:
xen 514173d3f8623194aa607f71866a240d02d432e8
baseline version:
xen fa062b2b9a49fa8f0cb44a3854a121b31f40c10d
Last test of basis 101938 2016-11-04 21:43:52 Z 18 days
Testing same since 102519 2016-11-22 13:42:50 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Ian Jackson <Ian.Jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm fail
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 fail
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 514173d3f8623194aa607f71866a240d02d432e8
Author: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue Nov 22 14:23:54 2016 +0100
pygrub: Properly quote results, when returning them to the caller:
* When the caller wants sexpr output, use `repr()'
This is what Xend expects.
The returned S-expressions are now escaped and quoted by Python,
generally using '...'. Previously kernel and ramdisk were unquoted
and args was quoted with "..." but without proper escaping. This
change may break toolstacks which do not properly dequote the
returned S-expressions.
* When the caller wants "simple" output, crash if the delimiter is
contained in the returned value.
With --output-format=simple it does not seem like this could ever
happen, because the bootloader config parsers all take line-based
input from the various bootloader config files.
With --output-format=simple0, this can happen if the bootloader
config file contains nul bytes.
This is CVE-2016-9379 and CVE-2016-9380 / XSA-198.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Tested-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 27e14d346ed6ff1c3a3cfc479507e62d133e92a9
master date: 2016-11-22 13:52:09 +0100
commit a4902cabfb3ac60db0e2bdaada05f550d985f0f3
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Nov 22 14:23:29 2016 +0100
x86/svm: fix injection of software interrupts
The non-NextRip logic in c/s 36ebf14eb "x86/emulate: support for emulating
software event injection" was based on an older version of the AMD software
manual. The manual was later corrected, following findings from that series.
I took the original wording of "not supported without NextRIP" to mean that
X86_EVENTTYPE_SW_INTERRUPT was not eligible for use. It turns out that this
is not the case, and the new wording is clearer on the matter.
Despite testing the original patch series on non-NRip hardware, the
swint-emulation XTF test case focuses on the debug vectors; it never ended up
executing an `int $n` instruction for a vector which wasn't also an exception.
During a vmentry, the use of X86_EVENTTYPE_HW_EXCEPTION comes with a vector
check to ensure that it is only used with exception vectors. Xen's use of
X86_EVENTTYPE_HW_EXCEPTION for `int $n` injection has always been buggy on AMD
hardware.
Fix this by always using X86_EVENTTYPE_SW_INTERRUPT.
Print and decode the eventinj information in svm_vmcb_dump(), as it has
several invalid combinations which cause vmentry failures.
This is CVE-2016-9378 / part of XSA-196.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 920edccd41db6cb0145545afa1850edf5e7d098e
master date: 2016-11-22 13:51:16 +0100
commit c03035b2af292e9054e3e0e0e99e560817b33681
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Nov 22 14:23:05 2016 +0100
x86/emul: correct the IDT entry calculation in inject_swint()
The logic, as introduced in c/s 36ebf14ebe "x86/emulate: support for emulating
software event injection" is buggy. The size of an IDT entry depends on long
mode being active, not the width of the code segment currently in use.
In particular, this means that a compatibility code segment which hits
emulation for software event injection will end up using an incorrect offset
in the IDT for DPL/Presence checking. In practice, this only occurs on old
AMD hardware lacking NRip support; all newer AMD hardware, and all Intel
hardware bypass this path in the emulator.
While here, fix a minor issue with reading the IDT entry. The return value
from ops->read() wasn't checked, but in reality the only failure case is if a
pagefault occurs. This is not a realistic problem as the kernel will almost
certainly crash with a double fault if this setup actually occured.
This is CVE-2016-9377 / part of XSA-196.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 255e8fe95f22ded5186fd75244ffcfb9d5dbc855
master date: 2016-11-22 13:50:49 +0100
commit e0fbb852806617ba9f991b98acc8bb6d1e802b50
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Nov 22 14:22:37 2016 +0100
x86emul: fix huge bit offset handling
We must never chop off the high 32 bits.
This is CVE-2016-9383 / XSA-195.
Reported-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 1c6c2d60d205f71ede0fbbd9047e459112f576db
master date: 2016-11-22 13:49:06 +0100
commit fcab9d3c6a539fc2928963f53d5a2cb6511d1b4b
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Nov 22 14:22:09 2016 +0100
x86/PV: writes of %fs and %gs base MSRs require canonical addresses
Commit c42494acb2 ("x86: fix FS/GS base handling when using the
fsgsbase feature") replaced the use of wrmsr_safe() on these paths
without recognizing that wr{f,g}sbase() use just wrmsrl() and that the
WR{F,G}SBASE instructions also raise #GP for non-canonical input.
Similarly arch_set_info_guest() needs to prevent non-canonical
addresses from getting stored into state later to be loaded by context
switch code. For consistency also check stack pointers and LDT base.
DR0..3, otoh, already get properly checked in set_debugreg() (albeit
we discard the error there).
The SHADOW_GS_BASE check isn't strictly necessary, but I think we
better avoid trying the WRMSR if we know it's going to fail.
This is CVE-2016-9385 / XSA-193.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: f3fa3abf3e61fb1f25ce721e14ac324dda67311f
master date: 2016-11-22 13:46:28 +0100
commit 46529a15223625f168be146a5df8442e8682fe4e
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Nov 22 14:21:34 2016 +0100
x86/HVM: don't load LDTR with VM86 mode attrs during task switch
Just like TR, LDTR is purely a protected mode facility and hence needs
to be loaded accordingly. Also move its loading to where it
architecurally belongs.
This is CVE-2016-9382 / XSA-192.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 93aa42b85ae0084ba7b749d0e990c94fbf0c17e3
master date: 2016-11-22 13:45:44 +0100
commit ffda12216868c75d3b2414997cbd847d4deab2d2
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Nov 22 14:20:58 2016 +0100
x86/hvm: Fix the handling of non-present segments
In 32bit, the data segments may be NULL to indicate that the segment is
ineligible for use. In both 32bit and 64bit, the LDT selector may be NULL to
indicate that the entire LDT is ineligible for use. However, nothing in Xen
actually checks for this condition when performing other segmentation
checks. (Note however that limit and writeability checks are correctly
performed).
Neither Intel nor AMD specify the exact behaviour of loading a NULL segment.
Experimentally, AMD zeroes all attributes but leaves the base and limit
unmodified. Intel zeroes the base, sets the limit to 0xfffffff and resets the
attributes to just .G and .D/B.
The use of the segment information in the VMCB/VMCS is equivalent to a native
pipeline interacting with the segment cache. The present bit can therefore
have a subtly different meaning, and it is now cooked to uniformly indicate
whether the segment is usable or not.
GDTR and IDTR don't have access rights like the other segments, but for
consistency, they are treated as being present so no special casing is needed
elsewhere in the segmentation logic.
AMD hardware does not consider the present bit for %cs and %tr, and will
function as if they were present. They are therefore unconditionally set to
present when reading information from the VMCB, to maintain the new meaning of
usability.
Intel hardware has a separate unusable bit in the VMCS segment attributes.
This bit is inverted and stored in the present field, so the hvm code can work
with architecturally-common state.
This is CVE-2016-9386 / XSA-191.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 04beafa8e6c66f5cd814c00e2d2b51cfbc41cb8a
master date: 2016-11-22 13:44:50 +0100
commit 805bb93aa093403f6c4b715be9106f0bb4866e86
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Nov 22 14:11:27 2016 +0100
update Xen version to 4.6.5-pre
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.6-testing test] 102519: regressions - FAIL
2016-11-23 4:11 [xen-4.6-testing test] 102519: regressions - FAIL osstest service owner
@ 2016-11-23 9:43 ` Jan Beulich
2016-11-23 9:49 ` Andrew Cooper
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2016-11-23 9:43 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, osstest-admin
>>> On 23.11.16 at 05:11, <osstest-admin@xenproject.org> wrote:
> flight 102519 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/102519/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 101938
> test-xtf-amd64-amd64-3 29 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 101938
> test-xtf-amd64-amd64-3 40 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 101938
Namely them representing a pattern, these concern me: Did we
screw up the backport for one of the XSAs? Otoh they succeeded
on 4.5. Or is this because the 4.6 ones ran on and AMD box,
while the 4.5 ones (and perhaps the earlier successful 4.6 flight
then too) made it onto an Intel system?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.6-testing test] 102519: regressions - FAIL
2016-11-23 9:43 ` Jan Beulich
@ 2016-11-23 9:49 ` Andrew Cooper
2016-11-23 10:25 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cooper @ 2016-11-23 9:49 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, osstest-admin
On 23/11/2016 09:43, Jan Beulich wrote:
>>>> On 23.11.16 at 05:11, <osstest-admin@xenproject.org> wrote:
>> flight 102519 xen-4.6-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/102519/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 101938
>> test-xtf-amd64-amd64-3 29 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 101938
>> test-xtf-amd64-amd64-3 40 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 101938
> Namely them representing a pattern, these concern me: Did we
> screw up the backport for one of the XSAs? Otoh they succeeded
> on 4.5. Or is this because the 4.6 ones ran on and AMD box,
> while the 4.5 ones (and perhaps the earlier successful 4.6 flight
> then too) made it onto an Intel system?
http://logs.test-lab.xenproject.org/osstest/logs/102519/test-xtf-amd64-amd64-3/nocera0---var-log-xen-console-guest-test-hvm32pae-invlpg~shadow.log
--- Xen Test Framework ---
Environment: HVM 32bit (PAE 3 levels)
Invlpg tests
Testing 'invlpg (0x1000)' with segment bases
Test: No segment
TLB refill of 0x1000
Test: %fs (base 0x0)
TLB refill of 0x1000
Test: %fs (base 0x0, limit 0x1)
Fail: Unexpected #GP[0000]
Fail: No TLB refill at all
Test: %fs (base 0x1000)
TLB refill of 0x2000
Test: %fs (base 0x1000, limit 0x1001)
TLB refill of 0x2000
Testing 'invlpg' in normally-faulting conditions
Test: Mapped address
Test: Unmapped address
Test: NULL segment override
Fail: Unexpected #GP[0000]
Test: Past segment limit
Fail: Unexpected #GP[0000]
Test: Before expand-down segment limit
Fail: Unexpected #GP[0000]
Test result: FAILURE
The invlpg logic isn't (or is no longer) squashing segmentation faults.
I can't recall whether you backported the change that far, but it looks
as if the test might accidentally been relying on XSA-191 to function on
older versions of Xen.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.6-testing test] 102519: regressions - FAIL
2016-11-23 9:49 ` Andrew Cooper
@ 2016-11-23 10:25 ` Jan Beulich
0 siblings, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2016-11-23 10:25 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, osstest-admin
>>> On 23.11.16 at 10:49, <andrew.cooper3@citrix.com> wrote:
> The invlpg logic isn't (or is no longer) squashing segmentation faults.
>
> I can't recall whether you backported the change that far, but it looks
> as if the test might accidentally been relying on XSA-191 to function on
> older versions of Xen.
That change didn't get backported anywhere so far. If it's
applicable to 4.6, we can certainly put it there. But it's obviously
absent in 4.5 too, and there the test succeeded (flight 102520).
Hence I'm afraid I don't fully understand your reply.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-11-23 10:25 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-23 4:11 [xen-4.6-testing test] 102519: regressions - FAIL osstest service owner
2016-11-23 9:43 ` Jan Beulich
2016-11-23 9:49 ` Andrew Cooper
2016-11-23 10:25 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.