* [linux-4.9 baseline test] 107238: tolerable FAIL
@ 2017-04-07 11:25 osstest service owner
2017-04-07 11:58 ` Ian Jackson
0 siblings, 1 reply; 29+ messages in thread
From: osstest service owner @ 2017-04-07 11:25 UTC (permalink / raw)
To: xen-devel, osstest-admin
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 107238 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107238/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 6 xen-boot fail never pass
test-armhf-armhf-xl-arndale 6 xen-boot fail never pass
test-armhf-armhf-libvirt 6 xen-boot fail never pass
test-armhf-armhf-libvirt-raw 6 xen-boot fail never pass
test-armhf-armhf-xl 6 xen-boot fail never pass
test-armhf-armhf-xl-vhd 6 xen-boot fail never pass
test-arm64-arm64-libvirt 12 migrate-support-check fail never pass
test-arm64-arm64-libvirt 13 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 12 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit2 12 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 13 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 12 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 13 saverestore-support-check fail never pass
test-arm64-arm64-xl 12 migrate-support-check fail never pass
test-arm64-arm64-xl 13 saverestore-support-check fail never pass
test-arm64-arm64-xl-multivcpu 12 migrate-support-check fail never pass
test-arm64-arm64-xl-multivcpu 13 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-arm64-arm64-xl-rtds 12 migrate-support-check fail never pass
test-arm64-arm64-xl-rtds 13 saverestore-support-check fail never pass
test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
test-armhf-armhf-libvirt-xsm 6 xen-boot fail never pass
test-arm64-arm64-libvirt-qcow2 11 migrate-support-check fail never pass
test-arm64-arm64-libvirt-qcow2 12 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-stop fail never pass
test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 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-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail never pass
version targeted for testing:
linux c8e131605de2e0d1d5769ff25272ae1c8e4720b0
baseline version:
linux c8e131605de2e0d1d5769ff25272ae1c8e4720b0
Last test of basis 107238 2017-04-06 10:22:37 Z 1 days
Testing same since 0 1970-01-01 00:00:00 Z 17263 days 0 attempts
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl fail
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
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-arm64-arm64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-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 pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 fail
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
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 pass
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 pass
test-amd64-i386-xl-qemuu-win7-amd64 pass
test-armhf-armhf-xl-arndale fail
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-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 fail
test-amd64-amd64-xl-pvh-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-arm64-arm64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-arm64-arm64-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-arm64-arm64-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-arm64-arm64-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 fail
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
Published tested tree is already up to date.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Please apply "partially revert "xen: Remove event channel..."
2017-04-07 11:25 [linux-4.9 baseline test] 107238: tolerable FAIL osstest service owner
@ 2017-04-07 11:58 ` Ian Jackson
0 siblings, 0 replies; 29+ messages in thread
From: Ian Jackson @ 2017-04-07 11:58 UTC (permalink / raw)
To: stable; +Cc: xen-devel, Stefano Stabellini, Boris Ostrovsky, Juergen Gross
tl;dr:
Please apply
da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
partially revert "xen: Remove event channel notification through
Xen PCI platform device"
to all stable branches which have a version of the original broken
commit. This includes at least 4.9.y.
Background:
osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
...
> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
osstest doesn't consider this a regresion because it looks for
regressions within a branch, and this is the first test of Linux 4.9.
However, this is a regression from the kernel we are currently using.
L1 dom0 console log:
http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
It seems to have got stuck halfway through booting.
The message
(XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
shows where osstest timed out on this test, and started its log
capture process (including collecting debug key output).
Complete logs for this job here:
http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
Juergen Gross tells me that this is due to the lack of
da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
Thanks,
Ian.
PS: Stefano, Boris: did you already request a backport of this commit?
If not, why not ?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Please apply "partially revert "xen: Remove event channel..."
@ 2017-04-07 11:58 ` Ian Jackson
0 siblings, 0 replies; 29+ messages in thread
From: Ian Jackson @ 2017-04-07 11:58 UTC (permalink / raw)
To: stable; +Cc: xen-devel, Stefano Stabellini, Boris Ostrovsky, Juergen Gross
tl;dr:
Please apply
da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
partially revert "xen: Remove event channel notification through
Xen PCI platform device"
to all stable branches which have a version of the original broken
commit. This includes at least 4.9.y.
Background:
osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
...
> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
osstest doesn't consider this a regresion because it looks for
regressions within a branch, and this is the first test of Linux 4.9.
However, this is a regression from the kernel we are currently using.
L1 dom0 console log:
http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
It seems to have got stuck halfway through booting.
The message
(XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
shows where osstest timed out on this test, and started its log
capture process (including collecting debug key output).
Complete logs for this job here:
http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
Juergen Gross tells me that this is due to the lack of
da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
Thanks,
Ian.
PS: Stefano, Boris: did you already request a backport of this commit?
If not, why not ?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-07 11:58 ` Ian Jackson
(?)
@ 2017-04-07 13:13 ` Boris Ostrovsky
2017-04-07 17:36 ` Stefano Stabellini
-1 siblings, 1 reply; 29+ messages in thread
From: Boris Ostrovsky @ 2017-04-07 13:13 UTC (permalink / raw)
To: Ian Jackson, stable; +Cc: xen-devel, Stefano Stabellini, Juergen Gross
On 04/07/2017 07:58 AM, Ian Jackson wrote:
> tl;dr:
> Please apply
>
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> partially revert "xen: Remove event channel notification through
> Xen PCI platform device"
>
> to all stable branches which have a version of the original broken
> commit. This includes at least 4.9.y.
>
> Background:
>
> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
> ...
>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
> osstest doesn't consider this a regresion because it looks for
> regressions within a branch, and this is the first test of Linux 4.9.
> However, this is a regression from the kernel we are currently using.
>
> L1 dom0 console log:
> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>
> It seems to have got stuck halfway through booting.
>
> The message
> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
> shows where osstest timed out on this test, and started its log
> capture process (including collecting debug key output).
>
> Complete logs for this job here:
> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>
> Juergen Gross tells me that this is due to the lack of
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>
> Thanks,
> Ian.
>
> PS: Stefano, Boris: did you already request a backport of this commit?
> If not, why not ?
No, but this should indeed be backported to 4.9+
-boris
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-07 13:13 ` Boris Ostrovsky
@ 2017-04-07 17:36 ` Stefano Stabellini
2017-04-07 17:43 ` Boris Ostrovsky
0 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2017-04-07 17:36 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Ian Jackson, stable, xen-devel, Stefano Stabellini, Juergen Gross
On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
> On 04/07/2017 07:58 AM, Ian Jackson wrote:
> > tl;dr:
> > Please apply
> >
> > da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> > partially revert "xen: Remove event channel notification through
> > Xen PCI platform device"
> >
> > to all stable branches which have a version of the original broken
> > commit. This includes at least 4.9.y.
> >
> > Background:
> >
> > osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
> > ...
> >> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
> > osstest doesn't consider this a regresion because it looks for
> > regressions within a branch, and this is the first test of Linux 4.9.
> > However, this is a regression from the kernel we are currently using.
> >
> > L1 dom0 console log:
> > http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
> >
> > It seems to have got stuck halfway through booting.
> >
> > The message
> > (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
> > shows where osstest timed out on this test, and started its log
> > capture process (including collecting debug key output).
> >
> > Complete logs for this job here:
> > http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
> >
> > Juergen Gross tells me that this is due to the lack of
> > da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
> >
> > Thanks,
> > Ian.
> >
> > PS: Stefano, Boris: did you already request a backport of this commit?
> > If not, why not ?
>
> No, but this should indeed be backported to 4.9+
Boris, are you going to do that?
While we wait for the kernel.org stable maintainers to do the backport,
would it help OSSTest if I backported
da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1 to the linux-arm-xen branch
myself now?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-07 17:36 ` Stefano Stabellini
@ 2017-04-07 17:43 ` Boris Ostrovsky
0 siblings, 0 replies; 29+ messages in thread
From: Boris Ostrovsky @ 2017-04-07 17:43 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Ian Jackson, stable, xen-devel, Juergen Gross
On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>> tl;dr:
>>> Please apply
>>>
>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>> partially revert "xen: Remove event channel notification through
>>> Xen PCI platform device"
>>>
>>> to all stable branches which have a version of the original broken
>>> commit. This includes at least 4.9.y.
>>>
>>> Background:
>>>
>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
>>> ...
>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
>>> osstest doesn't consider this a regresion because it looks for
>>> regressions within a branch, and this is the first test of Linux 4.9.
>>> However, this is a regression from the kernel we are currently using.
>>>
>>> L1 dom0 console log:
>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>
>>> It seems to have got stuck halfway through booting.
>>>
>>> The message
>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
>>> shows where osstest timed out on this test, and started its log
>>> capture process (including collecting debug key output).
>>>
>>> Complete logs for this job here:
>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>
>>> Juergen Gross tells me that this is due to the lack of
>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>
>>> Thanks,
>>> Ian.
>>>
>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>> If not, why not ?
>> No, but this should indeed be backported to 4.9+
> Boris, are you going to do that?
Is there anything that needs to be done beyond just applying it to 4.9
(4.10 apparently already has it).
-boris
>
> While we wait for the kernel.org stable maintainers to do the backport,
> would it help OSSTest if I backported
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1 to the linux-arm-xen branch
> myself now?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
@ 2017-04-07 17:43 ` Boris Ostrovsky
0 siblings, 0 replies; 29+ messages in thread
From: Boris Ostrovsky @ 2017-04-07 17:43 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Juergen Gross, xen-devel, Ian Jackson, stable
On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>> tl;dr:
>>> Please apply
>>>
>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>> partially revert "xen: Remove event channel notification through
>>> Xen PCI platform device"
>>>
>>> to all stable branches which have a version of the original broken
>>> commit. This includes at least 4.9.y.
>>>
>>> Background:
>>>
>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
>>> ...
>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
>>> osstest doesn't consider this a regresion because it looks for
>>> regressions within a branch, and this is the first test of Linux 4.9.
>>> However, this is a regression from the kernel we are currently using.
>>>
>>> L1 dom0 console log:
>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>
>>> It seems to have got stuck halfway through booting.
>>>
>>> The message
>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
>>> shows where osstest timed out on this test, and started its log
>>> capture process (including collecting debug key output).
>>>
>>> Complete logs for this job here:
>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>
>>> Juergen Gross tells me that this is due to the lack of
>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>
>>> Thanks,
>>> Ian.
>>>
>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>> If not, why not ?
>> No, but this should indeed be backported to 4.9+
> Boris, are you going to do that?
Is there anything that needs to be done beyond just applying it to 4.9
(4.10 apparently already has it).
-boris
>
> While we wait for the kernel.org stable maintainers to do the backport,
> would it help OSSTest if I backported
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1 to the linux-arm-xen branch
> myself now?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-07 17:43 ` Boris Ostrovsky
(?)
@ 2017-04-07 22:11 ` Stefano Stabellini
2017-04-10 13:47 ` Boris Ostrovsky
-1 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2017-04-07 22:11 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Stefano Stabellini, Ian Jackson, stable, xen-devel, Juergen Gross
On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
> > On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
> >> On 04/07/2017 07:58 AM, Ian Jackson wrote:
> >>> tl;dr:
> >>> Please apply
> >>>
> >>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> >>> partially revert "xen: Remove event channel notification through
> >>> Xen PCI platform device"
> >>>
> >>> to all stable branches which have a version of the original broken
> >>> commit. This includes at least 4.9.y.
> >>>
> >>> Background:
> >>>
> >>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
> >>> ...
> >>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
> >>> osstest doesn't consider this a regresion because it looks for
> >>> regressions within a branch, and this is the first test of Linux 4.9.
> >>> However, this is a regression from the kernel we are currently using.
> >>>
> >>> L1 dom0 console log:
> >>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
> >>>
> >>> It seems to have got stuck halfway through booting.
> >>>
> >>> The message
> >>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
> >>> shows where osstest timed out on this test, and started its log
> >>> capture process (including collecting debug key output).
> >>>
> >>> Complete logs for this job here:
> >>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
> >>>
> >>> Juergen Gross tells me that this is due to the lack of
> >>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
> >>>
> >>> Thanks,
> >>> Ian.
> >>>
> >>> PS: Stefano, Boris: did you already request a backport of this commit?
> >>> If not, why not ?
> >> No, but this should indeed be backported to 4.9+
> > Boris, are you going to do that?
>
> Is there anything that needs to be done beyond just applying it to 4.9
> (4.10 apparently already has it).
No, I don't think so. 4.9 already has the offending commit.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-07 22:11 ` Stefano Stabellini
@ 2017-04-10 13:47 ` Boris Ostrovsky
2017-04-10 13:57 ` Juergen Gross
0 siblings, 1 reply; 29+ messages in thread
From: Boris Ostrovsky @ 2017-04-10 13:47 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Ian Jackson, stable, xen-devel, Juergen Gross, KarimAllah Ahmed
On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>>>> tl;dr:
>>>>> Please apply
>>>>>
>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>>>> partially revert "xen: Remove event channel notification through
>>>>> Xen PCI platform device"
>>>>>
>>>>> to all stable branches which have a version of the original broken
>>>>> commit. This includes at least 4.9.y.
>>>>>
>>>>> Background:
>>>>>
>>>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
>>>>> ...
>>>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
>>>>> osstest doesn't consider this a regresion because it looks for
>>>>> regressions within a branch, and this is the first test of Linux 4.9.
>>>>> However, this is a regression from the kernel we are currently using.
>>>>>
>>>>> L1 dom0 console log:
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>>>
>>>>> It seems to have got stuck halfway through booting.
>>>>>
>>>>> The message
>>>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
>>>>> shows where osstest timed out on this test, and started its log
>>>>> capture process (including collecting debug key output).
>>>>>
>>>>> Complete logs for this job here:
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>>>
>>>>> Juergen Gross tells me that this is due to the lack of
>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>>>
>>>>> Thanks,
>>>>> Ian.
>>>>>
>>>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>>>> If not, why not ?
>>>> No, but this should indeed be backported to 4.9+
>>> Boris, are you going to do that?
>> Is there anything that needs to be done beyond just applying it to 4.9
>> (4.10 apparently already has it).
> No, I don't think so. 4.9 already has the offending commit.
Looks like there will be a new version of the original patch
(72a9b186292) so we should hold off with backport request to 4.9:
https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
-boris
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-10 13:47 ` Boris Ostrovsky
@ 2017-04-10 13:57 ` Juergen Gross
2017-04-10 14:12 ` Boris Ostrovsky
2017-04-10 15:32 ` Raslan, KarimAllah
0 siblings, 2 replies; 29+ messages in thread
From: Juergen Gross @ 2017-04-10 13:57 UTC (permalink / raw)
To: Boris Ostrovsky, Stefano Stabellini
Cc: Ian Jackson, stable, xen-devel, KarimAllah Ahmed
On 10/04/17 15:47, Boris Ostrovsky wrote:
> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>>>>> tl;dr:
>>>>>> Please apply
>>>>>>
>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>>>>> partially revert "xen: Remove event channel notification through
>>>>>> Xen PCI platform device"
>>>>>>
>>>>>> to all stable branches which have a version of the original broken
>>>>>> commit. This includes at least 4.9.y.
>>>>>>
>>>>>> Background:
>>>>>>
>>>>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
>>>>>> ...
>>>>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
>>>>>> osstest doesn't consider this a regresion because it looks for
>>>>>> regressions within a branch, and this is the first test of Linux 4.9.
>>>>>> However, this is a regression from the kernel we are currently using.
>>>>>>
>>>>>> L1 dom0 console log:
>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>>>>
>>>>>> It seems to have got stuck halfway through booting.
>>>>>>
>>>>>> The message
>>>>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
>>>>>> shows where osstest timed out on this test, and started its log
>>>>>> capture process (including collecting debug key output).
>>>>>>
>>>>>> Complete logs for this job here:
>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>>>>
>>>>>> Juergen Gross tells me that this is due to the lack of
>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>>>>
>>>>>> Thanks,
>>>>>> Ian.
>>>>>>
>>>>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>>>>> If not, why not ?
>>>>> No, but this should indeed be backported to 4.9+
>>>> Boris, are you going to do that?
>>> Is there anything that needs to be done beyond just applying it to 4.9
>>> (4.10 apparently already has it).
>> No, I don't think so. 4.9 already has the offending commit.
>
>
> Looks like there will be a new version of the original patch
> (72a9b186292) so we should hold off with backport request to 4.9:
>
> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
reworked: Do we really care for Xen versions < 4.0 and a theoretical
problem (after all the author admitted the bug isn't being hit in
reality due to a short-circuit in the code)?
And even if we do: I'd rather add another patch to stable later than
keeping a real bug in Linux 4.9 which has been hit at least 3 times
up to now (by Stefano, George and Ian).
Juergen
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-10 13:57 ` Juergen Gross
@ 2017-04-10 14:12 ` Boris Ostrovsky
2017-04-10 15:32 ` Raslan, KarimAllah
1 sibling, 0 replies; 29+ messages in thread
From: Boris Ostrovsky @ 2017-04-10 14:12 UTC (permalink / raw)
To: Juergen Gross, Stefano Stabellini
Cc: Ian Jackson, stable, xen-devel, KarimAllah Ahmed
On 04/10/2017 09:57 AM, Juergen Gross wrote:
> On 10/04/17 15:47, Boris Ostrovsky wrote:
>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>>>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>>>>>> tl;dr:
>>>>>>> Please apply
>>>>>>>
>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>>>>>> partially revert "xen: Remove event channel notification through
>>>>>>> Xen PCI platform device"
>>>>>>>
>>>>>>> to all stable branches which have a version of the original broken
>>>>>>> commit. This includes at least 4.9.y.
>>>>>>>
>>>>>>> Background:
>>>>>>>
>>>>>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
>>>>>>> ...
>>>>>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
>>>>>>> osstest doesn't consider this a regresion because it looks for
>>>>>>> regressions within a branch, and this is the first test of Linux 4.9.
>>>>>>> However, this is a regression from the kernel we are currently using.
>>>>>>>
>>>>>>> L1 dom0 console log:
>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>>>>>
>>>>>>> It seems to have got stuck halfway through booting.
>>>>>>>
>>>>>>> The message
>>>>>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
>>>>>>> shows where osstest timed out on this test, and started its log
>>>>>>> capture process (including collecting debug key output).
>>>>>>>
>>>>>>> Complete logs for this job here:
>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>>>>>
>>>>>>> Juergen Gross tells me that this is due to the lack of
>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ian.
>>>>>>>
>>>>>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>>>>>> If not, why not ?
>>>>>> No, but this should indeed be backported to 4.9+
>>>>> Boris, are you going to do that?
>>>> Is there anything that needs to be done beyond just applying it to 4.9
>>>> (4.10 apparently already has it).
>>> No, I don't think so. 4.9 already has the offending commit.
>>
>> Looks like there will be a new version of the original patch
>> (72a9b186292) so we should hold off with backport request to 4.9:
>>
>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
> reworked: Do we really care for Xen versions < 4.0 and a theoretical
> problem (after all the author admitted the bug isn't being hit in
> reality due to a short-circuit in the code)?
I don't know what the deal is with <4.0 Xen and I am not sure whether we
can boot new-ish Linux on those releases regardless of this specific
issue. I am certainly only testing Xen 4.1+ and have been doing this for
at least last 2-3 years.
>
> And even if we do: I'd rather add another patch to stable later than
> keeping a real bug in Linux 4.9 which has been hit at least 3 times
> up to now (by Stefano, George and Ian).
That would depend on how soon the new patch shows up.
-boris
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-10 13:57 ` Juergen Gross
2017-04-10 14:12 ` Boris Ostrovsky
@ 2017-04-10 15:32 ` Raslan, KarimAllah
2017-04-10 16:26 ` Juergen Gross
2017-04-11 8:57 ` Juergen Gross
1 sibling, 2 replies; 29+ messages in thread
From: Raslan, KarimAllah @ 2017-04-10 15:32 UTC (permalink / raw)
To: Juergen Gross
Cc: Boris Ostrovsky, Stefano Stabellini, Ian Jackson, stable, xen-devel
Ahmed, Karim Allah
karahmed@amazon.de
> On Apr 10, 2017, at 3:57 PM, Juergen Gross <jgross@suse.com> wrote:
>
> On 10/04/17 15:47, Boris Ostrovsky wrote:
>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>>>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>>>>>> tl;dr:
>>>>>>> Please apply
>>>>>>>
>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>>>>>> partially revert "xen: Remove event channel notification through
>>>>>>> Xen PCI platform device"
>>>>>>>
>>>>>>> to all stable branches which have a version of the original broken
>>>>>>> commit. This includes at least 4.9.y.
>>>>>>>
>>>>>>> Background:
>>>>>>>
>>>>>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
>>>>>>> ...
>>>>>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
>>>>>>> osstest doesn't consider this a regresion because it looks for
>>>>>>> regressions within a branch, and this is the first test of Linux 4.9.
>>>>>>> However, this is a regression from the kernel we are currently using.
>>>>>>>
>>>>>>> L1 dom0 console log:
>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>>>>>
>>>>>>> It seems to have got stuck halfway through booting.
>>>>>>>
>>>>>>> The message
>>>>>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
>>>>>>> shows where osstest timed out on this test, and started its log
>>>>>>> capture process (including collecting debug key output).
>>>>>>>
>>>>>>> Complete logs for this job here:
>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>>>>>
>>>>>>> Juergen Gross tells me that this is due to the lack of
>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ian.
>>>>>>>
>>>>>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>>>>>> If not, why not ?
>>>>>> No, but this should indeed be backported to 4.9+
>>>>> Boris, are you going to do that?
>>>> Is there anything that needs to be done beyond just applying it to 4.9
>>>> (4.10 apparently already has it).
>>> No, I don't think so. 4.9 already has the offending commit.
>>
>>
>> Looks like there will be a new version of the original patch
>> (72a9b186292) so we should hold off with backport request to 4.9:
>>
>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
>
> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
> reworked: Do we really care for Xen versions < 4.0 and a theoretical
> problem (after all the author admitted the bug isn't being hit in
> reality due to a short-circuit in the code)?
IMHO, even if 72a9b186292 has not been reworked we should completely revert it
not only partially revert it. Before this commit at least kernel 4.9+ would
work on older Xen versions (< 4.0) while now, it will not even boot.
I do agree however that fixing INTx sounds completely useless since there is
no combination of Xen+Linux that would lead to the bug by default (unless you
forced the use of INTx even when vector injection is supported which is what I
did during testing the original patch).
>
> And even if we do: I'd rather add another patch to stable later than
> keeping a real bug in Linux 4.9 which has been hit at least 3 times
> up to now (by Stefano, George and Ian).
>
>
> Juergen
>
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-10 15:32 ` Raslan, KarimAllah
@ 2017-04-10 16:26 ` Juergen Gross
2017-04-10 18:35 ` Stefano Stabellini
2017-04-11 8:57 ` Juergen Gross
1 sibling, 1 reply; 29+ messages in thread
From: Juergen Gross @ 2017-04-10 16:26 UTC (permalink / raw)
To: Raslan, KarimAllah, Boris Ostrovsky, Stefano Stabellini
Cc: xen-devel, Ian Jackson
On 10/04/17 17:32, Raslan, KarimAllah wrote:
>
> Ahmed, Karim Allah
> karahmed@amazon.de
>
>
>
>> On Apr 10, 2017, at 3:57 PM, Juergen Gross <jgross@suse.com> wrote:
>>
>> On 10/04/17 15:47, Boris Ostrovsky wrote:
>>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>>>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>>>>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>>>>>>> tl;dr:
>>>>>>>> Please apply
>>>>>>>>
>>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>>>>>>> partially revert "xen: Remove event channel notification through
>>>>>>>> Xen PCI platform device"
>>>>>>>>
>>>>>>>> to all stable branches which have a version of the original broken
>>>>>>>> commit. This includes at least 4.9.y.
>>>>>>>>
>>>>>>>> Background:
>>>>>>>>
>>>>>>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
>>>>>>>> ...
>>>>>>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
>>>>>>>> osstest doesn't consider this a regresion because it looks for
>>>>>>>> regressions within a branch, and this is the first test of Linux 4.9.
>>>>>>>> However, this is a regression from the kernel we are currently using.
>>>>>>>>
>>>>>>>> L1 dom0 console log:
>>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>>>>>>
>>>>>>>> It seems to have got stuck halfway through booting.
>>>>>>>>
>>>>>>>> The message
>>>>>>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
>>>>>>>> shows where osstest timed out on this test, and started its log
>>>>>>>> capture process (including collecting debug key output).
>>>>>>>>
>>>>>>>> Complete logs for this job here:
>>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>>>>>>
>>>>>>>> Juergen Gross tells me that this is due to the lack of
>>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ian.
>>>>>>>>
>>>>>>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>>>>>>> If not, why not ?
>>>>>>> No, but this should indeed be backported to 4.9+
>>>>>> Boris, are you going to do that?
>>>>> Is there anything that needs to be done beyond just applying it to 4.9
>>>>> (4.10 apparently already has it).
>>>> No, I don't think so. 4.9 already has the offending commit.
>>>
>>>
>>> Looks like there will be a new version of the original patch
>>> (72a9b186292) so we should hold off with backport request to 4.9:
>>>
>>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
>>
>> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
>> reworked: Do we really care for Xen versions < 4.0 and a theoretical
>> problem (after all the author admitted the bug isn't being hit in
>> reality due to a short-circuit in the code)?
>
> IMHO, even if 72a9b186292 has not been reworked we should completely revert it
> not only partially revert it. Before this commit at least kernel 4.9+ would
> work on older Xen versions (< 4.0) while now, it will not even boot.
The following is meant as a real question without any prejudice:
How old a Xen version do we want to support in the Linux kernel?
- Only those being still maintained (meaning getting security fixes)
- Versions max. X years after getting last security fixes (what value
of X?)
- From version Y on (what value of Y?)
- All versions which we can think of
I think we should answer this question in order to know what we can
remove in the Linux kernel without breaking something.
> I do agree however that fixing INTx sounds completely useless since there is
> no combination of Xen+Linux that would lead to the bug by default (unless you
> forced the use of INTx even when vector injection is supported which is what I
> did during testing the original patch).
Right.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-10 16:26 ` Juergen Gross
@ 2017-04-10 18:35 ` Stefano Stabellini
2017-04-10 18:48 ` Boris Ostrovsky
0 siblings, 1 reply; 29+ messages in thread
From: Stefano Stabellini @ 2017-04-10 18:35 UTC (permalink / raw)
To: Juergen Gross
Cc: Raslan, KarimAllah, Boris Ostrovsky, Stefano Stabellini,
Ian Jackson, xen-devel
On Mon, 10 Apr 2017, Juergen Gross wrote:
> On 10/04/17 17:32, Raslan, KarimAllah wrote:
> >
> > Ahmed, Karim Allah
> > karahmed@amazon.de
> >
> >
> >
> >> On Apr 10, 2017, at 3:57 PM, Juergen Gross <jgross@suse.com> wrote:
> >>
> >> On 10/04/17 15:47, Boris Ostrovsky wrote:
> >>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
> >>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
> >>>>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
> >>>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
> >>>>>>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
> >>>>>>>> tl;dr:
> >>>>>>>> Please apply
> >>>>>>>>
> >>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> >>>>>>>> partially revert "xen: Remove event channel notification through
> >>>>>>>> Xen PCI platform device"
> >>>>>>>>
> >>>>>>>> to all stable branches which have a version of the original broken
> >>>>>>>> commit. This includes at least 4.9.y.
> >>>>>>>>
> >>>>>>>> Background:
> >>>>>>>>
> >>>>>>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
> >>>>>>>> ...
> >>>>>>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
> >>>>>>>> osstest doesn't consider this a regresion because it looks for
> >>>>>>>> regressions within a branch, and this is the first test of Linux 4.9.
> >>>>>>>> However, this is a regression from the kernel we are currently using.
> >>>>>>>>
> >>>>>>>> L1 dom0 console log:
> >>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
> >>>>>>>>
> >>>>>>>> It seems to have got stuck halfway through booting.
> >>>>>>>>
> >>>>>>>> The message
> >>>>>>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
> >>>>>>>> shows where osstest timed out on this test, and started its log
> >>>>>>>> capture process (including collecting debug key output).
> >>>>>>>>
> >>>>>>>> Complete logs for this job here:
> >>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
> >>>>>>>>
> >>>>>>>> Juergen Gross tells me that this is due to the lack of
> >>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Ian.
> >>>>>>>>
> >>>>>>>> PS: Stefano, Boris: did you already request a backport of this commit?
> >>>>>>>> If not, why not ?
> >>>>>>> No, but this should indeed be backported to 4.9+
> >>>>>> Boris, are you going to do that?
> >>>>> Is there anything that needs to be done beyond just applying it to 4.9
> >>>>> (4.10 apparently already has it).
> >>>> No, I don't think so. 4.9 already has the offending commit.
> >>>
> >>>
> >>> Looks like there will be a new version of the original patch
> >>> (72a9b186292) so we should hold off with backport request to 4.9:
> >>>
> >>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
> >>
> >> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
> >> reworked: Do we really care for Xen versions < 4.0 and a theoretical
> >> problem (after all the author admitted the bug isn't being hit in
> >> reality due to a short-circuit in the code)?
> >
> > IMHO, even if 72a9b186292 has not been reworked we should completely revert it
> > not only partially revert it. Before this commit at least kernel 4.9+ would
> > work on older Xen versions (< 4.0) while now, it will not even boot.
>
> The following is meant as a real question without any prejudice:
>
> How old a Xen version do we want to support in the Linux kernel?
>
> - Only those being still maintained (meaning getting security fixes)
> - Versions max. X years after getting last security fixes (what value
> of X?)
> - From version Y on (what value of Y?)
> - All versions which we can think of
>
> I think we should answer this question in order to know what we can
> remove in the Linux kernel without breaking something.
Ideally, "All versions which we can think of", unless it becomes too
difficult. In that case, I would switch to "From version Y" where Y is
not troublesome to support (and older than the oldest supported Xen
release).
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-10 18:35 ` Stefano Stabellini
@ 2017-04-10 18:48 ` Boris Ostrovsky
2017-04-11 9:53 ` Andrew Cooper
0 siblings, 1 reply; 29+ messages in thread
From: Boris Ostrovsky @ 2017-04-10 18:48 UTC (permalink / raw)
To: Stefano Stabellini, Juergen Gross
Cc: Raslan, KarimAllah, xen-devel, Ian Jackson
>> The following is meant as a real question without any prejudice:
>>
>> How old a Xen version do we want to support in the Linux kernel?
>>
>> - Only those being still maintained (meaning getting security fixes)
Definitely not this. 4.4 is the oldest version receiving official XSA
patches and it's only 3 years old.
>> - Versions max. X years after getting last security fixes (what value
>> of X?)
>> - From version Y on (what value of Y?)
>> - All versions which we can think of
>>
>> I think we should answer this question in order to know what we can
>> remove in the Linux kernel without breaking something.
> Ideally, "All versions which we can think of", unless it becomes too
> difficult. In that case, I would switch to "From version Y" where Y is
> not troublesome to support (and older than the oldest supported Xen
> release).
So Oracle, for example, officially supports its virtualization product
for 8 to 10 years.
Which means that 10 years after a product is released it is possible to
see new version of Linux on such a product (although realistically
vendors may generally support more limited sets of guests).
If we are to follow this line of reasoning Xen 3.4 needs to be supported
--- it was released in 2009.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-10 15:32 ` Raslan, KarimAllah
2017-04-10 16:26 ` Juergen Gross
@ 2017-04-11 8:57 ` Juergen Gross
2017-04-11 14:26 ` Raslan, KarimAllah
1 sibling, 1 reply; 29+ messages in thread
From: Juergen Gross @ 2017-04-11 8:57 UTC (permalink / raw)
To: Raslan, KarimAllah
Cc: Boris Ostrovsky, Stefano Stabellini, Ian Jackson, stable, xen-devel
On 10/04/17 17:32, Raslan, KarimAllah wrote:
>
> Ahmed, Karim Allah
> karahmed@amazon.de
>
>
>
>> On Apr 10, 2017, at 3:57 PM, Juergen Gross <jgross@suse.com> wrote:
>>
>> On 10/04/17 15:47, Boris Ostrovsky wrote:
>>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>>>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>>>>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>>>>>>> tl;dr:
>>>>>>>> Please apply
>>>>>>>>
>>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>>>>>>> partially revert "xen: Remove event channel notification through
>>>>>>>> Xen PCI platform device"
>>>>>>>>
>>>>>>>> to all stable branches which have a version of the original broken
>>>>>>>> commit. This includes at least 4.9.y.
>>>>>>>>
>>>>>>>> Background:
>>>>>>>>
>>>>>>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
>>>>>>>> ...
>>>>>>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
>>>>>>>> osstest doesn't consider this a regresion because it looks for
>>>>>>>> regressions within a branch, and this is the first test of Linux 4.9.
>>>>>>>> However, this is a regression from the kernel we are currently using.
>>>>>>>>
>>>>>>>> L1 dom0 console log:
>>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>>>>>>
>>>>>>>> It seems to have got stuck halfway through booting.
>>>>>>>>
>>>>>>>> The message
>>>>>>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
>>>>>>>> shows where osstest timed out on this test, and started its log
>>>>>>>> capture process (including collecting debug key output).
>>>>>>>>
>>>>>>>> Complete logs for this job here:
>>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>>>>>>
>>>>>>>> Juergen Gross tells me that this is due to the lack of
>>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ian.
>>>>>>>>
>>>>>>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>>>>>>> If not, why not ?
>>>>>>> No, but this should indeed be backported to 4.9+
>>>>>> Boris, are you going to do that?
>>>>> Is there anything that needs to be done beyond just applying it to 4.9
>>>>> (4.10 apparently already has it).
>>>> No, I don't think so. 4.9 already has the offending commit.
>>>
>>>
>>> Looks like there will be a new version of the original patch
>>> (72a9b186292) so we should hold off with backport request to 4.9:
>>>
>>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
>>
>> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
>> reworked: Do we really care for Xen versions < 4.0 and a theoretical
>> problem (after all the author admitted the bug isn't being hit in
>> reality due to a short-circuit in the code)?
>
> IMHO, even if 72a9b186292 has not been reworked we should completely revert it
> not only partially revert it. Before this commit at least kernel 4.9+ would
> work on older Xen versions (< 4.0) while now, it will not even boot.
Just to make sure we understand which Xen versions are to be
supported: which Xen versions are you at Amazon currently using?
Juergen
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-10 18:48 ` Boris Ostrovsky
@ 2017-04-11 9:53 ` Andrew Cooper
2017-04-11 13:22 ` Boris Ostrovsky
0 siblings, 1 reply; 29+ messages in thread
From: Andrew Cooper @ 2017-04-11 9:53 UTC (permalink / raw)
To: Boris Ostrovsky, Stefano Stabellini, Juergen Gross
Cc: Raslan, KarimAllah, xen-devel, Ian Jackson
On 10/04/17 19:48, Boris Ostrovsky wrote:
>>> The following is meant as a real question without any prejudice:
>>>
>>> How old a Xen version do we want to support in the Linux kernel?
>>>
>>> - Only those being still maintained (meaning getting security fixes)
> Definitely not this. 4.4 is the oldest version receiving official XSA
> patches and it's only 3 years old.
>
>>> - Versions max. X years after getting last security fixes (what value
>>> of X?)
>>> - From version Y on (what value of Y?)
>>> - All versions which we can think of
>>>
>>> I think we should answer this question in order to know what we can
>>> remove in the Linux kernel without breaking something.
>> Ideally, "All versions which we can think of", unless it becomes too
>> difficult. In that case, I would switch to "From version Y" where Y is
>> not troublesome to support (and older than the oldest supported Xen
>> release).
> So Oracle, for example, officially supports its virtualization product
> for 8 to 10 years.
>
> Which means that 10 years after a product is released it is possible to
> see new version of Linux on such a product (although realistically
> vendors may generally support more limited sets of guests).
>
> If we are to follow this line of reasoning Xen 3.4 needs to be supported
> --- it was released in 2009.
Citrix XenServer is also 10 years.
From what I understand, SUSE are still supporting Xen 3.2 based
products, which is the same kind of vintage.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-11 9:53 ` Andrew Cooper
@ 2017-04-11 13:22 ` Boris Ostrovsky
2017-04-11 13:47 ` Juergen Gross
0 siblings, 1 reply; 29+ messages in thread
From: Boris Ostrovsky @ 2017-04-11 13:22 UTC (permalink / raw)
To: Andrew Cooper, Stefano Stabellini, Juergen Gross
Cc: Raslan, KarimAllah, xen-devel, Ian Jackson
On 04/11/2017 05:53 AM, Andrew Cooper wrote:
> On 10/04/17 19:48, Boris Ostrovsky wrote:
>>>> The following is meant as a real question without any prejudice:
>>>>
>>>> How old a Xen version do we want to support in the Linux kernel?
>>>>
>>>> - Only those being still maintained (meaning getting security fixes)
>> Definitely not this. 4.4 is the oldest version receiving official XSA
>> patches and it's only 3 years old.
>>
>>>> - Versions max. X years after getting last security fixes (what value
>>>> of X?)
>>>> - From version Y on (what value of Y?)
>>>> - All versions which we can think of
>>>>
>>>> I think we should answer this question in order to know what we can
>>>> remove in the Linux kernel without breaking something.
>>> Ideally, "All versions which we can think of", unless it becomes too
>>> difficult. In that case, I would switch to "From version Y" where Y is
>>> not troublesome to support (and older than the oldest supported Xen
>>> release).
>> So Oracle, for example, officially supports its virtualization product
>> for 8 to 10 years.
>>
>> Which means that 10 years after a product is released it is possible to
>> see new version of Linux on such a product (although realistically
>> vendors may generally support more limited sets of guests).
>>
>> If we are to follow this line of reasoning Xen 3.4 needs to be supported
>> --- it was released in 2009.
>
> Citrix XenServer is also 10 years.
>
> From what I understand, SUSE are still supporting Xen 3.2 based
> products, which is the same kind of vintage.
I think the right thing is indeed to revert 72a9b186292 (and therefore
da72ff5bfcb02). Any objections?
The only possible remaining issue is that kernels not using vector
callbacks running on post-4.0 Xen won't work. But we always use
callbacks if they are available (and they are post 4.0).
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-11 13:22 ` Boris Ostrovsky
@ 2017-04-11 13:47 ` Juergen Gross
2017-04-11 14:10 ` Boris Ostrovsky
0 siblings, 1 reply; 29+ messages in thread
From: Juergen Gross @ 2017-04-11 13:47 UTC (permalink / raw)
To: Boris Ostrovsky, Andrew Cooper, Stefano Stabellini
Cc: Raslan, KarimAllah, xen-devel, Ian Jackson
On 11/04/17 15:22, Boris Ostrovsky wrote:
>
>
> On 04/11/2017 05:53 AM, Andrew Cooper wrote:
>> On 10/04/17 19:48, Boris Ostrovsky wrote:
>>>>> The following is meant as a real question without any
>>>>> prejudice:
>>>>>
>>>>> How old a Xen version do we want to support in the Linux
>>>>> kernel?
>>>>>
>>>>> - Only those being still maintained (meaning getting security
>>>>> fixes)
>>> Definitely not this. 4.4 is the oldest version receiving official
>>> XSA patches and it's only 3 years old.
>>>
>>>>> - Versions max. X years after getting last security fixes
>>>>> (what value of X?) - From version Y on (what value of Y?) -
>>>>> All versions which we can think of
>>>>>
>>>>> I think we should answer this question in order to know what
>>>>> we can remove in the Linux kernel without breaking
>>>>> something.
>>>> Ideally, "All versions which we can think of", unless it
>>>> becomes too difficult. In that case, I would switch to "From
>>>> version Y" where Y is not troublesome to support (and older
>>>> than the oldest supported Xen release).
>>> So Oracle, for example, officially supports its virtualization
>>> product for 8 to 10 years.
>>>
>>> Which means that 10 years after a product is released it is
>>> possible to see new version of Linux on such a product (although
>>> realistically vendors may generally support more limited sets of
>>> guests).
>>>
>>> If we are to follow this line of reasoning Xen 3.4 needs to be
>>> supported --- it was released in 2009.
>>
>> Citrix XenServer is also 10 years.
>>
>> From what I understand, SUSE are still supporting Xen 3.2 based
>> products, which is the same kind of vintage.
>
>
> I think the right thing is indeed to revert 72a9b186292 (and
> therefore da72ff5bfcb02). Any objections?
For the end result: depends. Is there a real error or not?
KarimAllah wrote that his concerns are of a theoretical nature as
xen_strict_xenbus_quirk() would mask the problem. OTOH he tells us
a 4.9 kernel wouldn't even boot on Xen < 4.0. What is correct here?
For just reverting the two commits: yes, as there would be conflicts
with already applied patches, especially the pv isolation patches by
Vitaly and pvh v1 removal.
So in case we need a revert I'd ask KarimAllah to send a fixup patch
restoring the state before 72a9b186292 while respecting the new
structure to be found on the for-linus-4.12 branch of xen/tip.
> The only possible remaining issue is that kernels not using vector
> callbacks running on post-4.0 Xen won't work. But we always use
> callbacks if they are available (and they are post 4.0).
I guess this is a non-issue, as it worked until 4.9.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-11 13:47 ` Juergen Gross
@ 2017-04-11 14:10 ` Boris Ostrovsky
2017-04-11 14:42 ` Raslan, KarimAllah
0 siblings, 1 reply; 29+ messages in thread
From: Boris Ostrovsky @ 2017-04-11 14:10 UTC (permalink / raw)
To: Juergen Gross, Andrew Cooper, Stefano Stabellini
Cc: Raslan, KarimAllah, xen-devel, Ian Jackson
>>
>> I think the right thing is indeed to revert 72a9b186292 (and
>> therefore da72ff5bfcb02). Any objections?
>
> For the end result: depends. Is there a real error or not?
> KarimAllah wrote that his concerns are of a theoretical nature as
> xen_strict_xenbus_quirk() would mask the problem. OTOH he tells us
> a 4.9 kernel wouldn't even boot on Xen < 4.0. What is correct here?
Judged by 'BUG_ON(!xen_feature(XENFEAT_hvm_callback_vector))' in
xen_hvm_guest_init() this can't boot on 3.4.
>
> For just reverting the two commits: yes, as there would be conflicts
> with already applied patches, especially the pv isolation patches by
> Vitaly and pvh v1 removal.
>
> So in case we need a revert I'd ask KarimAllah to send a fixup patch
> restoring the state before 72a9b186292 while respecting the new
> structure to be found on the for-linus-4.12 branch of xen/tip.
Stable trees (4.9 and 4.10) need a pure revert. 4.11 indeed requires
some extra work (and 4.12 is even more involved).
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-11 8:57 ` Juergen Gross
@ 2017-04-11 14:26 ` Raslan, KarimAllah
0 siblings, 0 replies; 29+ messages in thread
From: Raslan, KarimAllah @ 2017-04-11 14:26 UTC (permalink / raw)
To: Juergen Gross
Cc: Boris Ostrovsky, Stefano Stabellini, Ian Jackson, stable, xen-devel
> On Apr 11, 2017, at 10:57 AM, Juergen Gross <jgross@suse.com> wrote:
>
> On 10/04/17 17:32, Raslan, KarimAllah wrote:
>>
>> Ahmed, Karim Allah
>> karahmed@amazon.de
>>
>>
>>
>>> On Apr 10, 2017, at 3:57 PM, Juergen Gross <jgross@suse.com> wrote:
>>>
>>> On 10/04/17 15:47, Boris Ostrovsky wrote:
>>>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>>>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>>>>>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>>>>>>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>>>>>>>> tl;dr:
>>>>>>>>> Please apply
>>>>>>>>>
>>>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>>>>>>>> partially revert "xen: Remove event channel notification through
>>>>>>>>> Xen PCI platform device"
>>>>>>>>>
>>>>>>>>> to all stable branches which have a version of the original broken
>>>>>>>>> commit. This includes at least 4.9.y.
>>>>>>>>>
>>>>>>>>> Background:
>>>>>>>>>
>>>>>>>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: tolerable FAIL"):
>>>>>>>>> ...
>>>>>>>>>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
>>>>>>>>> osstest doesn't consider this a regresion because it looks for
>>>>>>>>> regressions within a branch, and this is the first test of Linux 4.9.
>>>>>>>>> However, this is a regression from the kernel we are currently using.
>>>>>>>>>
>>>>>>>>> L1 dom0 console log:
>>>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>>>>>>>
>>>>>>>>> It seems to have got stuck halfway through booting.
>>>>>>>>>
>>>>>>>>> The message
>>>>>>>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0)
>>>>>>>>> shows where osstest timed out on this test, and started its log
>>>>>>>>> capture process (including collecting debug key output).
>>>>>>>>>
>>>>>>>>> Complete logs for this job here:
>>>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>>>>>>>
>>>>>>>>> Juergen Gross tells me that this is due to the lack of
>>>>>>>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Ian.
>>>>>>>>>
>>>>>>>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>>>>>>>> If not, why not ?
>>>>>>>> No, but this should indeed be backported to 4.9+
>>>>>>> Boris, are you going to do that?
>>>>>> Is there anything that needs to be done beyond just applying it to 4.9
>>>>>> (4.10 apparently already has it).
>>>>> No, I don't think so. 4.9 already has the offending commit.
>>>>
>>>>
>>>> Looks like there will be a new version of the original patch
>>>> (72a9b186292) so we should hold off with backport request to 4.9:
>>>>
>>>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
>>>
>>> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
>>> reworked: Do we really care for Xen versions < 4.0 and a theoretical
>>> problem (after all the author admitted the bug isn't being hit in
>>> reality due to a short-circuit in the code)?
>>
>> IMHO, even if 72a9b186292 has not been reworked we should completely revert it
>> not only partially revert it. Before this commit at least kernel 4.9+ would
>> work on older Xen versions (< 4.0) while now, it will not even boot.
>
> Just to make sure we understand which Xen versions are to be
> supported: which Xen versions are you at Amazon currently using?
The majority of Amazon fleet is > 4.0 (4.2) but some old generation stuff
is still running Xen 3.4.
>
>
> Juergen
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-11 14:10 ` Boris Ostrovsky
@ 2017-04-11 14:42 ` Raslan, KarimAllah
2017-04-11 14:47 ` Juergen Gross
0 siblings, 1 reply; 29+ messages in thread
From: Raslan, KarimAllah @ 2017-04-11 14:42 UTC (permalink / raw)
To: Boris Ostrovsky
Cc: Juergen Gross, Andrew Cooper, Stefano Stabellini, Ian Jackson, xen-devel
> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
>
>
>
>>>
>>> I think the right thing is indeed to revert 72a9b186292 (and
>>> therefore da72ff5bfcb02). Any objections?
>>
>> For the end result: depends. Is there a real error or not?
>> KarimAllah wrote that his concerns are of a theoretical nature as
>> xen_strict_xenbus_quirk() would mask the problem. OTOH he tells us
>> a 4.9 kernel wouldn't even boot on Xen < 4.0. What is correct here?
>
>
> Judged by 'BUG_ON(!xen_feature(XENFEAT_hvm_callback_vector))' in xen_hvm_guest_init() this can't boot on 3.4.
Correct.
Here is the brief summary of the current situation:
Before the offending commit (72a9b186292):
1) INTx does not work because of the reset_watches path.
2) The reset_watches path is only taken if you have Xen > 4.0
3) The Linux Kernel by default will use vector inject if the hypervisor
support. So even INTx does not work no body running the kernel with Xen > 4.0
would notice. Unless he explicitly disabled this feature either in the kernel
or in Xen (and this can only be disabled by modifying the code, not
user-supported way to do it).
After the offending commit (+ partial revert):
1) INTx is no longer support for HVM (only for PV guests).
2) Any HVM guest The kernel will not boot on Xen < 4.0 which does not have
vector injection support. Since the only other mode supported is INTx which.
So based on this summary, I think before commit (72a9b186292) we were in much
better position from a user point of view.
>
>
>>
>> For just reverting the two commits: yes, as there would be conflicts
>> with already applied patches, especially the pv isolation patches by
>> Vitaly and pvh v1 removal.
>>
>> So in case we need a revert I'd ask KarimAllah to send a fixup patch
>> restoring the state before 72a9b186292 while respecting the new
>> structure to be found on the for-linus-4.12 branch of xen/tip.
>
> Stable trees (4.9 and 4.10) need a pure revert. 4.11 indeed requires some extra work (and 4.12 is even more involved).
If we agreed on going forward with the revert, I will take care of sending the
patches to revert for various trees.
>
> -boris
>
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-11 14:42 ` Raslan, KarimAllah
@ 2017-04-11 14:47 ` Juergen Gross
0 siblings, 0 replies; 29+ messages in thread
From: Juergen Gross @ 2017-04-11 14:47 UTC (permalink / raw)
To: Raslan, KarimAllah, Boris Ostrovsky
Cc: Andrew Cooper, Stefano Stabellini, Ian Jackson, xen-devel
On 11/04/17 16:42, Raslan, KarimAllah wrote:
>
>> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
>>
>>
>>
>>>>
>>>> I think the right thing is indeed to revert 72a9b186292 (and
>>>> therefore da72ff5bfcb02). Any objections?
>>>
>>> For the end result: depends. Is there a real error or not?
>>> KarimAllah wrote that his concerns are of a theoretical nature as
>>> xen_strict_xenbus_quirk() would mask the problem. OTOH he tells us
>>> a 4.9 kernel wouldn't even boot on Xen < 4.0. What is correct here?
>>
>>
>> Judged by 'BUG_ON(!xen_feature(XENFEAT_hvm_callback_vector))' in xen_hvm_guest_init() this can't boot on 3.4.
>
> Correct.
>
> Here is the brief summary of the current situation:
>
> Before the offending commit (72a9b186292):
>
> 1) INTx does not work because of the reset_watches path.
> 2) The reset_watches path is only taken if you have Xen > 4.0
> 3) The Linux Kernel by default will use vector inject if the hypervisor
> support. So even INTx does not work no body running the kernel with Xen > 4.0
> would notice. Unless he explicitly disabled this feature either in the kernel
> or in Xen (and this can only be disabled by modifying the code, not
> user-supported way to do it).
>
> After the offending commit (+ partial revert):
>
> 1) INTx is no longer support for HVM (only for PV guests).
> 2) Any HVM guest The kernel will not boot on Xen < 4.0 which does not have
> vector injection support. Since the only other mode supported is INTx which.
>
> So based on this summary, I think before commit (72a9b186292) we were in much
> better position from a user point of view.
Thanks for this summary. With this information I agree reverting is the
best option.
>>> For just reverting the two commits: yes, as there would be conflicts
>>> with already applied patches, especially the pv isolation patches by
>>> Vitaly and pvh v1 removal.
>>>
>>> So in case we need a revert I'd ask KarimAllah to send a fixup patch
>>> restoring the state before 72a9b186292 while respecting the new
>>> structure to be found on the for-linus-4.12 branch of xen/tip.
>>
>> Stable trees (4.9 and 4.10) need a pure revert. 4.11 indeed requires some extra work (and 4.12 is even more involved).
>
> If we agreed on going forward with the revert, I will take care of sending the
> patches to revert for various trees.
Yes, please go ahead.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-07 11:58 ` Ian Jackson
(?)
(?)
@ 2017-04-12 13:13 ` Greg KH
2017-04-12 13:26 ` Juergen Gross
-1 siblings, 1 reply; 29+ messages in thread
From: Greg KH @ 2017-04-12 13:13 UTC (permalink / raw)
To: Ian Jackson
Cc: stable, xen-devel, Stefano Stabellini, Boris Ostrovsky, Juergen Gross
On Fri, Apr 07, 2017 at 12:58:14PM +0100, Ian Jackson wrote:
> tl;dr:
> Please apply
>
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> partially revert "xen: Remove event channel notification through
> Xen PCI platform device"
>
> to all stable branches which have a version of the original broken
> commit. This includes at least 4.9.y.
Is this still true? This long thread is totally confusing, is that what
you really want to have happen? Anything else?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-12 13:13 ` Greg KH
@ 2017-04-12 13:26 ` Juergen Gross
2017-04-12 13:34 ` Greg KH
0 siblings, 1 reply; 29+ messages in thread
From: Juergen Gross @ 2017-04-12 13:26 UTC (permalink / raw)
To: Greg KH, Ian Jackson
Cc: stable, xen-devel, Stefano Stabellini, Boris Ostrovsky
On 12/04/17 15:13, Greg KH wrote:
> On Fri, Apr 07, 2017 at 12:58:14PM +0100, Ian Jackson wrote:
>> tl;dr:
>> Please apply
>>
>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>> partially revert "xen: Remove event channel notification through
>> Xen PCI platform device"
>>
>> to all stable branches which have a version of the original broken
>> commit. This includes at least 4.9.y.
>
> Is this still true? This long thread is totally confusing, is that what
> you really want to have happen? Anything else?
Please ignore this request. We will send another one to fully revert the
original patch leading to the current situation.
Juergen
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-12 13:26 ` Juergen Gross
@ 2017-04-12 13:34 ` Greg KH
2017-04-12 13:44 ` Ian Jackson
0 siblings, 1 reply; 29+ messages in thread
From: Greg KH @ 2017-04-12 13:34 UTC (permalink / raw)
To: Juergen Gross
Cc: Ian Jackson, stable, xen-devel, Stefano Stabellini, Boris Ostrovsky
On Wed, Apr 12, 2017 at 03:26:53PM +0200, Juergen Gross wrote:
> On 12/04/17 15:13, Greg KH wrote:
> > On Fri, Apr 07, 2017 at 12:58:14PM +0100, Ian Jackson wrote:
> >> tl;dr:
> >> Please apply
> >>
> >> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> >> partially revert "xen: Remove event channel notification through
> >> Xen PCI platform device"
> >>
> >> to all stable branches which have a version of the original broken
> >> commit. This includes at least 4.9.y.
> >
> > Is this still true? This long thread is totally confusing, is that what
> > you really want to have happen? Anything else?
>
> Please ignore this request. We will send another one to fully revert the
> original patch leading to the current situation.
Now ignored!
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-12 13:34 ` Greg KH
@ 2017-04-12 13:44 ` Ian Jackson
2017-04-12 16:24 ` Juergen Gross
2017-05-11 12:26 ` Juergen Gross
0 siblings, 2 replies; 29+ messages in thread
From: Ian Jackson @ 2017-04-12 13:44 UTC (permalink / raw)
To: Juergen Gross, xen-devel, Stefano Stabellini, Boris Ostrovsky
Greg KH writes ("Re: Please apply "partially revert "xen: Remove event channel...""):
> On Wed, Apr 12, 2017 at 03:26:53PM +0200, Juergen Gross wrote:
> > On 12/04/17 15:13, Greg KH wrote:
> > > Is this still true? This long thread is totally confusing, is that what
> > > you really want to have happen? Anything else?
Quite!
> > Please ignore this request. We will send another one to fully revert the
> > original patch leading to the current situation.
Thanks for clarifying this. (In future, perhaps kernel folks could
take charge of requesting backports as appropriate, when the stable
kernel branches break, so that I don't have to blunder about making
inappropriate requests...)
Can someone please let me know when this is fixed ? This is blocking
switching osstest's default kernel to something more modern.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-12 13:44 ` Ian Jackson
@ 2017-04-12 16:24 ` Juergen Gross
2017-05-11 12:26 ` Juergen Gross
1 sibling, 0 replies; 29+ messages in thread
From: Juergen Gross @ 2017-04-12 16:24 UTC (permalink / raw)
To: Ian Jackson, xen-devel, Stefano Stabellini, Boris Ostrovsky
On 12/04/17 15:44, Ian Jackson wrote:
> Greg KH writes ("Re: Please apply "partially revert "xen: Remove event channel...""):
>> On Wed, Apr 12, 2017 at 03:26:53PM +0200, Juergen Gross wrote:
>>> On 12/04/17 15:13, Greg KH wrote:
>>>> Is this still true? This long thread is totally confusing, is that what
>>>> you really want to have happen? Anything else?
>
> Quite!
>
>>> Please ignore this request. We will send another one to fully revert the
>>> original patch leading to the current situation.
>
> Thanks for clarifying this. (In future, perhaps kernel folks could
> take charge of requesting backports as appropriate, when the stable
> kernel branches break, so that I don't have to blunder about making
> inappropriate requests...)
The request wasn't inappropriate. It was just bad luck regarding the
timing.
> Can someone please let me know when this is fixed ? This is blocking
> switching osstest's default kernel to something more modern.
Sure.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Please apply "partially revert "xen: Remove event channel..."
2017-04-12 13:44 ` Ian Jackson
2017-04-12 16:24 ` Juergen Gross
@ 2017-05-11 12:26 ` Juergen Gross
1 sibling, 0 replies; 29+ messages in thread
From: Juergen Gross @ 2017-05-11 12:26 UTC (permalink / raw)
To: Ian Jackson, xen-devel, Stefano Stabellini, Boris Ostrovsky
On 12/04/17 15:44, Ian Jackson wrote:
> Greg KH writes ("Re: Please apply "partially revert "xen: Remove event channel...""):
>> On Wed, Apr 12, 2017 at 03:26:53PM +0200, Juergen Gross wrote:
>>> On 12/04/17 15:13, Greg KH wrote:
>>>> Is this still true? This long thread is totally confusing, is that what
>>>> you really want to have happen? Anything else?
>
> Quite!
>
>>> Please ignore this request. We will send another one to fully revert the
>>> original patch leading to the current situation.
>
> Thanks for clarifying this. (In future, perhaps kernel folks could
> take charge of requesting backports as appropriate, when the stable
> kernel branches break, so that I don't have to blunder about making
> inappropriate requests...)
>
> Can someone please let me know when this is fixed ? This is blocking
> switching osstest's default kernel to something more modern.
Greg just sent the mail that he has applied the patch to the
linux-4.9.y stable tree.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2017-05-11 12:26 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-07 11:25 [linux-4.9 baseline test] 107238: tolerable FAIL osstest service owner
2017-04-07 11:58 ` Please apply "partially revert "xen: Remove event channel..." Ian Jackson
2017-04-07 11:58 ` Ian Jackson
2017-04-07 13:13 ` Boris Ostrovsky
2017-04-07 17:36 ` Stefano Stabellini
2017-04-07 17:43 ` Boris Ostrovsky
2017-04-07 17:43 ` Boris Ostrovsky
2017-04-07 22:11 ` Stefano Stabellini
2017-04-10 13:47 ` Boris Ostrovsky
2017-04-10 13:57 ` Juergen Gross
2017-04-10 14:12 ` Boris Ostrovsky
2017-04-10 15:32 ` Raslan, KarimAllah
2017-04-10 16:26 ` Juergen Gross
2017-04-10 18:35 ` Stefano Stabellini
2017-04-10 18:48 ` Boris Ostrovsky
2017-04-11 9:53 ` Andrew Cooper
2017-04-11 13:22 ` Boris Ostrovsky
2017-04-11 13:47 ` Juergen Gross
2017-04-11 14:10 ` Boris Ostrovsky
2017-04-11 14:42 ` Raslan, KarimAllah
2017-04-11 14:47 ` Juergen Gross
2017-04-11 8:57 ` Juergen Gross
2017-04-11 14:26 ` Raslan, KarimAllah
2017-04-12 13:13 ` Greg KH
2017-04-12 13:26 ` Juergen Gross
2017-04-12 13:34 ` Greg KH
2017-04-12 13:44 ` Ian Jackson
2017-04-12 16:24 ` Juergen Gross
2017-05-11 12:26 ` Juergen Gross
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.