[linux-4.9 baseline test] 107238: tolerable FAIL

[linux-4.9 baseline test] 107238: tolerable FAIL

[osstest service owner]

"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

Please apply "partially revert "xen: Remove event channel..."

[Ian Jackson]

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 ?

Please apply "partially revert "xen: Remove event channel..."

[Ian Jackson]

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 ?

Re: Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Stefano Stabellini]

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?

Re: Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

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?

Re: Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Stefano Stabellini]

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.

Re: Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Raslan, KarimAllah]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Stefano Stabellini]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Andrew Cooper]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Raslan, KarimAllah]

> 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

Re: Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Raslan, KarimAllah]

> 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

Re: Please apply "partially revert "xen: Remove event channel..."

[Greg KH]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Greg KH]

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!

Re: Please apply "partially revert "xen: Remove event channel..."

[Ian Jackson]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

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

Re: Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

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