[xen-unstable-smoke bisection] complete build-amd64-libvirt

[xen-unstable-smoke bisection] complete build-amd64-libvirt

[osstest service owner]

branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64-libvirt
testid libvirt-build

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  929f23114061a0089e6d63d109cf6a1d03d35c71
  Bug not present: 8bc342b043a6838c03cd86039a34e3f8eea1242f
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/157589/


  commit 929f23114061a0089e6d63d109cf6a1d03d35c71
  Author: Paul Durrant <pdurrant@amazon.com>
  Date:   Tue Dec 8 19:30:26 2020 +0000
  
      libxl: introduce 'libxl_pci_bdf' in the idl...
      
      ... and use in 'libxl_device_pci'
      
      This patch is preparatory work for restricting the type passed to functions
      that only require BDF information, rather than passing a 'libxl_device_pci'
      structure which is only partially filled. In this patch only the minimal
      mechanical changes necessary to deal with the structural changes are made.
      Subsequent patches will adjust the code to make better use of the new type.
      
      Signed-off-by: Paul Durrant <pdurrant@amazon.com>
      Acked-by: Wei Liu <wl@xen.org>
      Acked-by: Nick Rosbrook <rosbrookn@ainfosec.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64-libvirt.libvirt-build --summary-out=tmp/157589.bisection-summary --basis-template=157560 --blessings=real,real-bisect,real-retry xen-unstable-smoke build-amd64-libvirt libvirt-build
Searching for failure / basis pass:
 157575 fail [host=himrod2] / 157560 ok.
Failure / basis pass flights: 157575 / 157560
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 8bf0fab14256057bbd145563151814300476bb28
Basis pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 904148ecb4a59d4c8375d8e8d38117b8605e10ac
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/libvirt.git#2c846fa6bcc11929c9fb857a22430fb9945654ad-2c846fa6bcc11929c9fb857a22430fb9945654ad https://gitlab.com/keycodemap/keycodemapdb.git#27acf0ef828bf719b2053ba398b195829413dbdd-27acf0ef828bf719b2053ba398b195829413dbdd git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#7ea428895af2840d85c524f0bd11a38aac308\
 308-7ea428895af2840d85c524f0bd11a38aac308308 git://xenbits.xen.org/xen.git#904148ecb4a59d4c8375d8e8d38117b8605e10ac-8bf0fab14256057bbd145563151814300476bb28
Loaded 5001 nodes in revision graph
Searching for test results:
 157560 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 904148ecb4a59d4c8375d8e8d38117b8605e10ac
 157570 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 8bf0fab14256057bbd145563151814300476bb28
 157574 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 904148ecb4a59d4c8375d8e8d38117b8605e10ac
 157577 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 8bf0fab14256057bbd145563151814300476bb28
 157575 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 8bf0fab14256057bbd145563151814300476bb28
 157579 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 4951b9ea807d4a4e5a54798d366b2ea3d6ca5060
 157580 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 8bc342b043a6838c03cd86039a34e3f8eea1242f
 157581 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 66c2fbc6e82b1aa7b9f0fb37eecf93983c348058
 157583 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 96ed6ff29741df820217b6b744eb0fa2d76b50f3
 157585 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 929f23114061a0089e6d63d109cf6a1d03d35c71
 157586 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 8bc342b043a6838c03cd86039a34e3f8eea1242f
 157587 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 929f23114061a0089e6d63d109cf6a1d03d35c71
 157588 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 8bc342b043a6838c03cd86039a34e3f8eea1242f
 157589 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 929f23114061a0089e6d63d109cf6a1d03d35c71
Searching for interesting versions
 Result found: flight 157560 (pass), for basis pass
 For basis failure, parent search stopping at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 8bc342b043a6838c03cd86039a34e3f8eea1242f, results HASH(0x564e75a40ce8) HASH(0x564e75a40fe8) HASH(0x564e75a3ee60) For basis failure, parent search stopping at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895\
 af2840d85c524f0bd11a38aac308308 4951b9ea807d4a4e5a54798d366b2ea3d6ca5060, results HASH(0x564e75a3ece0) For basis failure, parent search stopping at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 904148ecb4a59d4c8375d8e8d38117b8605e10ac, results HASH(0x564e75a34368) HASH(0x564e75a2d5a8) Result found: flight 157570 (fail), for basis failure (at ancestor ~674)
 Repro found: flight 157574 (pass), for basis pass
 Repro found: flight 157575 (fail), for basis failure
 0 revisions at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 8bc342b043a6838c03cd86039a34e3f8eea1242f
No revisions left to test, checking graph state.
 Result found: flight 157580 (pass), for last pass
 Result found: flight 157585 (fail), for first failure
 Repro found: flight 157586 (pass), for last pass
 Repro found: flight 157587 (fail), for first failure
 Repro found: flight 157588 (pass), for last pass
 Repro found: flight 157589 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  929f23114061a0089e6d63d109cf6a1d03d35c71
  Bug not present: 8bc342b043a6838c03cd86039a34e3f8eea1242f
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/157589/


  commit 929f23114061a0089e6d63d109cf6a1d03d35c71
  Author: Paul Durrant <pdurrant@amazon.com>
  Date:   Tue Dec 8 19:30:26 2020 +0000
  
      libxl: introduce 'libxl_pci_bdf' in the idl...
      
      ... and use in 'libxl_device_pci'
      
      This patch is preparatory work for restricting the type passed to functions
      that only require BDF information, rather than passing a 'libxl_device_pci'
      structure which is only partially filled. In this patch only the minimal
      mechanical changes necessary to deal with the structural changes are made.
      Subsequent patches will adjust the code to make better use of the new type.
      
      Signed-off-by: Paul Durrant <pdurrant@amazon.com>
      Acked-by: Wei Liu <wl@xen.org>
      Acked-by: Nick Rosbrook <rosbrookn@ainfosec.com>

Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-amd64-libvirt.libvirt-build.{dot,ps,png,html,svg}.
----------------------------------------
157589: tolerable ALL FAIL

flight 157589 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/157589/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build           fail baseline untested


jobs:
 build-amd64-libvirt                                          fail    


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

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Andrew Cooper]

On 16/12/2020 02:27, osstest service owner wrote:
> branch xen-unstable-smoke
> xenbranch xen-unstable-smoke
> job build-amd64-libvirt
> testid libvirt-build
>
> Tree: libvirt git://xenbits.xen.org/libvirt.git
> Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
>
> *** Found and reproduced problem changeset ***
>
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  929f23114061a0089e6d63d109cf6a1d03d35c71
>   Bug not present: 8bc342b043a6838c03cd86039a34e3f8eea1242f
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/157589/
>
>
>   commit 929f23114061a0089e6d63d109cf6a1d03d35c71
>   Author: Paul Durrant <pdurrant@amazon.com>
>   Date:   Tue Dec 8 19:30:26 2020 +0000
>   
>       libxl: introduce 'libxl_pci_bdf' in the idl...
>       
>       ... and use in 'libxl_device_pci'
>       
>       This patch is preparatory work for restricting the type passed to functions
>       that only require BDF information, rather than passing a 'libxl_device_pci'
>       structure which is only partially filled. In this patch only the minimal
>       mechanical changes necessary to deal with the structural changes are made.
>       Subsequent patches will adjust the code to make better use of the new type.
>       
>       Signed-off-by: Paul Durrant <pdurrant@amazon.com>
>       Acked-by: Wei Liu <wl@xen.org>
>       Acked-by: Nick Rosbrook <rosbrookn@ainfosec.com>

This breaks the API.  You can't make the following change in the IDL.

 libxl_device_pci = Struct("device_pci", [
-    ("func",      uint8),
-    ("dev",       uint8),
-    ("bus",       uint8),
-    ("domain",    integer),
-    ("vdevfn",    uint32),
+    ("bdf", libxl_pci_bdf),
+    ("vdevfn", uint32),

~Andrew

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Wei Liu]

Paul, are you able to cook up a patch today? If not I will revert the
offending patch(es).

Wei.

On Wed, Dec 16, 2020 at 10:17:29AM +0000, Andrew Cooper wrote:
> On 16/12/2020 02:27, osstest service owner wrote:
> > branch xen-unstable-smoke
> > xenbranch xen-unstable-smoke
> > job build-amd64-libvirt
> > testid libvirt-build
> >
> > Tree: libvirt git://xenbits.xen.org/libvirt.git
> > Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
> > Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> > Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> > Tree: xen git://xenbits.xen.org/xen.git
> >
> > *** Found and reproduced problem changeset ***
> >
> >   Bug is in tree:  xen git://xenbits.xen.org/xen.git
> >   Bug introduced:  929f23114061a0089e6d63d109cf6a1d03d35c71
> >   Bug not present: 8bc342b043a6838c03cd86039a34e3f8eea1242f
> >   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/157589/
> >
> >
> >   commit 929f23114061a0089e6d63d109cf6a1d03d35c71
> >   Author: Paul Durrant <pdurrant@amazon.com>
> >   Date:   Tue Dec 8 19:30:26 2020 +0000
> >   
> >       libxl: introduce 'libxl_pci_bdf' in the idl...
> >       
> >       ... and use in 'libxl_device_pci'
> >       
> >       This patch is preparatory work for restricting the type passed to functions
> >       that only require BDF information, rather than passing a 'libxl_device_pci'
> >       structure which is only partially filled. In this patch only the minimal
> >       mechanical changes necessary to deal with the structural changes are made.
> >       Subsequent patches will adjust the code to make better use of the new type.
> >       
> >       Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> >       Acked-by: Wei Liu <wl@xen.org>
> >       Acked-by: Nick Rosbrook <rosbrookn@ainfosec.com>
> 
> This breaks the API.  You can't make the following change in the IDL.
> 
>  libxl_device_pci = Struct("device_pci", [
> -    ("func",      uint8),
> -    ("dev",       uint8),
> -    ("bus",       uint8),
> -    ("domain",    integer),
> -    ("vdevfn",    uint32),
> +    ("bdf", libxl_pci_bdf),
> +    ("vdevfn", uint32),
> 
> ~Andrew

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Wei Liu]

On Wed, Dec 16, 2020 at 10:43:57AM +0000, Wei Liu wrote:
> Paul, are you able to cook up a patch today? If not I will revert the
> offending patch(es).
> 

I've reverted the offending 8 patches for now.

Wei.

RE: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Paul Durrant]

> -----Original Message-----
> From: Wei Liu <wl@xen.org>
> Sent: 16 December 2020 10:44
> To: Andrew Cooper <andrew.cooper3@citrix.com>; Paul Durrant <paul@xen.org>
> Cc: osstest service owner <osstest-admin@xenproject.org>; xen-devel@lists.xenproject.org; Paul Durrant
> <paul@xen.org>; Wei Liu <wl@xen.org>
> Subject: Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
> 
> Paul, are you able to cook up a patch today? If not I will revert the
> offending patch(es).
> 

Sorry I was otherwise occupied yesterday. It's not so simple to avoid the API change the way things are in the series... it will
take a reasonable amount of re-factoring to avoid it. I'll re-base and fix it.

  Paul

> Wei.
> 
> On Wed, Dec 16, 2020 at 10:17:29AM +0000, Andrew Cooper wrote:
> > On 16/12/2020 02:27, osstest service owner wrote:
> > > branch xen-unstable-smoke
> > > xenbranch xen-unstable-smoke
> > > job build-amd64-libvirt
> > > testid libvirt-build
> > >
> > > Tree: libvirt git://xenbits.xen.org/libvirt.git
> > > Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
> > > Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> > > Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> > > Tree: xen git://xenbits.xen.org/xen.git
> > >
> > > *** Found and reproduced problem changeset ***
> > >
> > >   Bug is in tree:  xen git://xenbits.xen.org/xen.git
> > >   Bug introduced:  929f23114061a0089e6d63d109cf6a1d03d35c71
> > >   Bug not present: 8bc342b043a6838c03cd86039a34e3f8eea1242f
> > >   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/157589/
> > >
> > >
> > >   commit 929f23114061a0089e6d63d109cf6a1d03d35c71
> > >   Author: Paul Durrant <pdurrant@amazon.com>
> > >   Date:   Tue Dec 8 19:30:26 2020 +0000
> > >
> > >       libxl: introduce 'libxl_pci_bdf' in the idl...
> > >
> > >       ... and use in 'libxl_device_pci'
> > >
> > >       This patch is preparatory work for restricting the type passed to functions
> > >       that only require BDF information, rather than passing a 'libxl_device_pci'
> > >       structure which is only partially filled. In this patch only the minimal
> > >       mechanical changes necessary to deal with the structural changes are made.
> > >       Subsequent patches will adjust the code to make better use of the new type.
> > >
> > >       Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> > >       Acked-by: Wei Liu <wl@xen.org>
> > >       Acked-by: Nick Rosbrook <rosbrookn@ainfosec.com>
> >
> > This breaks the API.  You can't make the following change in the IDL.
> >
> >  libxl_device_pci = Struct("device_pci", [
> > -    ("func",      uint8),
> > -    ("dev",       uint8),
> > -    ("bus",       uint8),
> > -    ("domain",    integer),
> > -    ("vdevfn",    uint32),
> > +    ("bdf", libxl_pci_bdf),
> > +    ("vdevfn", uint32),
> >
> > ~Andrew

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Julien Grall]

Hi,

On 02/08/2022 11:58, Julien Grall wrote:
> On 01/08/2022 14:15, Andrew Cooper wrote:
>> The testing situation with libvirt is already bad.  I don't think a
>> force push is going to make it meaningfully worse.
> 
> I have forced pushed to the branch smoke using the flight 171899. For 
> staging, it looks like the latest flight was testing f732240f, so we 
> don't have one with the libvirt patches.
> 
> I am hoping the push to the smoke branch will trigger a xen-unstable 
> flight.

master has now been forced push as well.

Cheers,


-- 
Julien Grall

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Julien Grall]

Hi,

On 01/08/2022 14:15, Andrew Cooper wrote:
> On 01/08/2022 09:43, Julien Grall wrote:
>> (+ Committers)
>>
>> Hi Jan,
>>
>> On 01/08/2022 09:36, Jan Beulich wrote:
>>> On 29.07.2022 19:36, Julien Grall wrote:
>>>> Hi Jan,
>>>>
>>>> On 29/07/2022 07:22, Jan Beulich wrote:
>>>>> On 29.07.2022 03:04, osstest service owner wrote:
>>>>>> branch xen-unstable-smoke
>>>>>> xenbranch xen-unstable-smoke
>>>>>> job build-amd64-libvirt
>>>>>> testid libvirt-build
>>>>>>
>>>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>>>>> Tree: libvirt_keycodemapdb
>>>>>> https://gitlab.com/keycodemap/keycodemapdb.git
>>>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>>>>> Tree: xen git://xenbits.xen.org/xen.git
>>>>>>
>>>>>> *** Found and reproduced problem changeset ***
>>>>>>
>>>>>>      Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>>>>      Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>>      Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>>>>      Last fail repro:
>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/171909/
>>>>>>
>>>>>>
>>>>>>      commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>>      Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>>      Date:   Fri Jul 15 22:20:24 2022 +0300
>>>>>>              libxl: Add support for Virtio disk configuration
>>>>>
>>>>> Just in case you didn't notice it: Something's wrong here. I didn't
>>>>> look
>>>>> at the details at all. Please advise whether a fix will soon arrive or
>>>>> whether we should revert for the time being.
>>>>
>>>> We had discussion on IRC about this today. This is an issue in libvirt
>>>> rather than Xen. So I think a revert is not warrant here.
>>>>
>>>> Instead, it was suggested to force push because it is going to take
>>>> some
>>>> times to fix libvirt (see more below).
>>>>
>>>> Oleksandr already sent a patch to fix libvirt [1]. The problem is even
>>>> if this is accepted, our testing branch for libvirt is 2 years behind
>>>> because they switched to Meson and Osstest has not been adapted to the
>>>> new build system.
>>>>
>>>> Anthony kindly offered to update Osstest.
>>>>
>>>> Regarding force pushing, I am waiting for the Osstest result to confirm
>>>> that only the libvirt tests are failing in staging (we already have the
>>>> results for smoke). So my plan is to force push on Monday.
>>>>
>>>> Please let me know on Monday morning if you have some concerns with
>>>> this
>>>> approach.
>>>
>>> Actually I do - if we force push, the libvirt failure will stick, and
>>> hence potential further regressions introduced there would not be
>>> noticed.
>>
>> Well... We haven't had any push in libvirt for the past 2 years. So to
>> me it shows that nobody really care about the testing done. Therefore,
>> I don't see the problem if we don't spot further regressions.
>>
>> If we don't force push, we have two solutions:
>>    1) Revert Oleksandr's series
>>    2) Leave it until we have Osstest fixed *and* Oleksandr's patch
>> reached libvirt.
>>
>> The former is not an option for me, because Oleksandr's series is not
>> at fault. So this leave us to 2).
>>
>> So what's your proposal?
> 
> This situation is unfortunate, but Oleksandr's series is not at fault,
> and I don't think it is reasonable for libxl changes to be held hostage
> like this.
> 
> The testing situation with libvirt is already bad.  I don't think a
> force push is going to make it meaningfully worse.

I have forced pushed to the branch smoke using the flight 171899. For 
staging, it looks like the latest flight was testing f732240f, so we 
don't have one with the libvirt patches.

I am hoping the push to the smoke branch will trigger a xen-unstable flight.

Cheers,

-- 
Julien Grall

RE: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Henry Wang]

Hi Jan, Julien,

> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Subject: Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
> 
> Hi Jan,
> 
> On 01/08/2022 10:06, Jan Beulich wrote:
> > On 01.08.2022 10:43, Julien Grall wrote:
> >> If we don't force push, we have two solutions:
> >>     1) Revert Oleksandr's series
> >>     2) Leave it until we have Osstest fixed *and* Oleksandr's patch
> >> reached libvirt.
> >>
> >> The former is not an option for me, because Oleksandr's series is not at
> >> fault. So this leave us to 2).
> >>
> >> So what's your proposal?
> >
> > It's still 1), no matter that I agree that Oleksandr's series is not
> > directly at fault.
> 
> My worry is while we have a plan to address the libvirt issues, I am not
> confident this could be addressed by Xen 4.17. In particular, Osstest
> has to be fixed and we need a push.
> 
> I think this is a bit unfair to block the virtio series on the recent
> lack of investment in libvirt testing.
> 
> So if we end up to revert it, this will need to be a block for Xen 4.17.

I will try to track this for Xen 4.17 release.

Kind regards,
Henry

> 
> Cheers,
> 
> --
> Julien Grall

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Andrew Cooper]

On 01/08/2022 09:43, Julien Grall wrote:
> (+ Committers)
>
> Hi Jan,
>
> On 01/08/2022 09:36, Jan Beulich wrote:
>> On 29.07.2022 19:36, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 29/07/2022 07:22, Jan Beulich wrote:
>>>> On 29.07.2022 03:04, osstest service owner wrote:
>>>>> branch xen-unstable-smoke
>>>>> xenbranch xen-unstable-smoke
>>>>> job build-amd64-libvirt
>>>>> testid libvirt-build
>>>>>
>>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>>>> Tree: libvirt_keycodemapdb
>>>>> https://gitlab.com/keycodemap/keycodemapdb.git
>>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>>>> Tree: xen git://xenbits.xen.org/xen.git
>>>>>
>>>>> *** Found and reproduced problem changeset ***
>>>>>
>>>>>     Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>>>     Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>     Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>>>     Last fail repro:
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/171909/
>>>>>
>>>>>
>>>>>     commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>     Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>     Date:   Fri Jul 15 22:20:24 2022 +0300
>>>>>             libxl: Add support for Virtio disk configuration
>>>>
>>>> Just in case you didn't notice it: Something's wrong here. I didn't
>>>> look
>>>> at the details at all. Please advise whether a fix will soon arrive or
>>>> whether we should revert for the time being.
>>>
>>> We had discussion on IRC about this today. This is an issue in libvirt
>>> rather than Xen. So I think a revert is not warrant here.
>>>
>>> Instead, it was suggested to force push because it is going to take
>>> some
>>> times to fix libvirt (see more below).
>>>
>>> Oleksandr already sent a patch to fix libvirt [1]. The problem is even
>>> if this is accepted, our testing branch for libvirt is 2 years behind
>>> because they switched to Meson and Osstest has not been adapted to the
>>> new build system.
>>>
>>> Anthony kindly offered to update Osstest.
>>>
>>> Regarding force pushing, I am waiting for the Osstest result to confirm
>>> that only the libvirt tests are failing in staging (we already have the
>>> results for smoke). So my plan is to force push on Monday.
>>>
>>> Please let me know on Monday morning if you have some concerns with
>>> this
>>> approach.
>>
>> Actually I do - if we force push, the libvirt failure will stick, and
>> hence potential further regressions introduced there would not be
>> noticed.
>
> Well... We haven't had any push in libvirt for the past 2 years. So to
> me it shows that nobody really care about the testing done. Therefore,
> I don't see the problem if we don't spot further regressions.
>
> If we don't force push, we have two solutions:
>   1) Revert Oleksandr's series
>   2) Leave it until we have Osstest fixed *and* Oleksandr's patch
> reached libvirt.
>
> The former is not an option for me, because Oleksandr's series is not
> at fault. So this leave us to 2).
>
> So what's your proposal?

This situation is unfortunate, but Oleksandr's series is not at fault,
and I don't think it is reasonable for libxl changes to be held hostage
like this.

The testing situation with libvirt is already bad.  I don't think a
force push is going to make it meaningfully worse.

~Andrew

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Julien Grall]

Hi Jan,

On 01/08/2022 10:06, Jan Beulich wrote:
> On 01.08.2022 10:43, Julien Grall wrote:
>> If we don't force push, we have two solutions:
>>     1) Revert Oleksandr's series
>>     2) Leave it until we have Osstest fixed *and* Oleksandr's patch
>> reached libvirt.
>>
>> The former is not an option for me, because Oleksandr's series is not at
>> fault. So this leave us to 2).
>>
>> So what's your proposal?
> 
> It's still 1), no matter that I agree that Oleksandr's series is not
> directly at fault.

My worry is while we have a plan to address the libvirt issues, I am not 
confident this could be addressed by Xen 4.17. In particular, Osstest 
has to be fixed and we need a push.

I think this is a bit unfair to block the virtio series on the recent 
lack of investment in libvirt testing.

So if we end up to revert it, this will need to be a block for Xen 4.17.

Cheers,

-- 
Julien Grall

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Jan Beulich]

On 01.08.2022 10:43, Julien Grall wrote:
> (+ Committers)
> 
> Hi Jan,
> 
> On 01/08/2022 09:36, Jan Beulich wrote:
>> On 29.07.2022 19:36, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 29/07/2022 07:22, Jan Beulich wrote:
>>>> On 29.07.2022 03:04, osstest service owner wrote:
>>>>> branch xen-unstable-smoke
>>>>> xenbranch xen-unstable-smoke
>>>>> job build-amd64-libvirt
>>>>> testid libvirt-build
>>>>>
>>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>>>> Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
>>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>>>> Tree: xen git://xenbits.xen.org/xen.git
>>>>>
>>>>> *** Found and reproduced problem changeset ***
>>>>>
>>>>>     Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>>>     Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>     Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>>>     Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/171909/
>>>>>
>>>>>
>>>>>     commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>     Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>     Date:   Fri Jul 15 22:20:24 2022 +0300
>>>>>     
>>>>>         libxl: Add support for Virtio disk configuration
>>>>
>>>> Just in case you didn't notice it: Something's wrong here. I didn't look
>>>> at the details at all. Please advise whether a fix will soon arrive or
>>>> whether we should revert for the time being.
>>>
>>> We had discussion on IRC about this today. This is an issue in libvirt
>>> rather than Xen. So I think a revert is not warrant here.
>>>
>>> Instead, it was suggested to force push because it is going to take some
>>> times to fix libvirt (see more below).
>>>
>>> Oleksandr already sent a patch to fix libvirt [1]. The problem is even
>>> if this is accepted, our testing branch for libvirt is 2 years behind
>>> because they switched to Meson and Osstest has not been adapted to the
>>> new build system.
>>>
>>> Anthony kindly offered to update Osstest.
>>>
>>> Regarding force pushing, I am waiting for the Osstest result to confirm
>>> that only the libvirt tests are failing in staging (we already have the
>>> results for smoke). So my plan is to force push on Monday.
>>>
>>> Please let me know on Monday morning if you have some concerns with this
>>> approach.
>>
>> Actually I do - if we force push, the libvirt failure will stick, and
>> hence potential further regressions introduced there would not be noticed.
> 
> Well... We haven't had any push in libvirt for the past 2 years. So to 
> me it shows that nobody really care about the testing done. Therefore, I 
> don't see the problem if we don't spot further regressions.

I don't understand, or maybe I did express myself ambiguously: I'm not
talking about libvirt regressions (in their code base), but about changes
in our code regressing libvirt.

> If we don't force push, we have two solutions:
>    1) Revert Oleksandr's series
>    2) Leave it until we have Osstest fixed *and* Oleksandr's patch 
> reached libvirt.
> 
> The former is not an option for me, because Oleksandr's series is not at 
> fault. So this leave us to 2).
> 
> So what's your proposal?

It's still 1), no matter that I agree that Oleksandr's series is not
directly at fault.

Jan

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Julien Grall]

(+ Committers)

Hi Jan,

On 01/08/2022 09:36, Jan Beulich wrote:
> On 29.07.2022 19:36, Julien Grall wrote:
>> Hi Jan,
>>
>> On 29/07/2022 07:22, Jan Beulich wrote:
>>> On 29.07.2022 03:04, osstest service owner wrote:
>>>> branch xen-unstable-smoke
>>>> xenbranch xen-unstable-smoke
>>>> job build-amd64-libvirt
>>>> testid libvirt-build
>>>>
>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>>> Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>>> Tree: xen git://xenbits.xen.org/xen.git
>>>>
>>>> *** Found and reproduced problem changeset ***
>>>>
>>>>     Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>>     Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>     Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>>     Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/171909/
>>>>
>>>>
>>>>     commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>     Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>     Date:   Fri Jul 15 22:20:24 2022 +0300
>>>>     
>>>>         libxl: Add support for Virtio disk configuration
>>>
>>> Just in case you didn't notice it: Something's wrong here. I didn't look
>>> at the details at all. Please advise whether a fix will soon arrive or
>>> whether we should revert for the time being.
>>
>> We had discussion on IRC about this today. This is an issue in libvirt
>> rather than Xen. So I think a revert is not warrant here.
>>
>> Instead, it was suggested to force push because it is going to take some
>> times to fix libvirt (see more below).
>>
>> Oleksandr already sent a patch to fix libvirt [1]. The problem is even
>> if this is accepted, our testing branch for libvirt is 2 years behind
>> because they switched to Meson and Osstest has not been adapted to the
>> new build system.
>>
>> Anthony kindly offered to update Osstest.
>>
>> Regarding force pushing, I am waiting for the Osstest result to confirm
>> that only the libvirt tests are failing in staging (we already have the
>> results for smoke). So my plan is to force push on Monday.
>>
>> Please let me know on Monday morning if you have some concerns with this
>> approach.
> 
> Actually I do - if we force push, the libvirt failure will stick, and
> hence potential further regressions introduced there would not be noticed.

Well... We haven't had any push in libvirt for the past 2 years. So to 
me it shows that nobody really care about the testing done. Therefore, I 
don't see the problem if we don't spot further regressions.

If we don't force push, we have two solutions:
   1) Revert Oleksandr's series
   2) Leave it until we have Osstest fixed *and* Oleksandr's patch 
reached libvirt.

The former is not an option for me, because Oleksandr's series is not at 
fault. So this leave us to 2).

So what's your proposal?

Cheers,

-- 
Julien Grall

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Jan Beulich]

On 29.07.2022 19:36, Julien Grall wrote:
> Hi Jan,
> 
> On 29/07/2022 07:22, Jan Beulich wrote:
>> On 29.07.2022 03:04, osstest service owner wrote:
>>> branch xen-unstable-smoke
>>> xenbranch xen-unstable-smoke
>>> job build-amd64-libvirt
>>> testid libvirt-build
>>>
>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>> Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>> Tree: xen git://xenbits.xen.org/xen.git
>>>
>>> *** Found and reproduced problem changeset ***
>>>
>>>    Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>    Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>    Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>    Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/171909/
>>>
>>>
>>>    commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>    Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>    Date:   Fri Jul 15 22:20:24 2022 +0300
>>>    
>>>        libxl: Add support for Virtio disk configuration
>>
>> Just in case you didn't notice it: Something's wrong here. I didn't look
>> at the details at all. Please advise whether a fix will soon arrive or
>> whether we should revert for the time being.
> 
> We had discussion on IRC about this today. This is an issue in libvirt 
> rather than Xen. So I think a revert is not warrant here.
> 
> Instead, it was suggested to force push because it is going to take some 
> times to fix libvirt (see more below).
> 
> Oleksandr already sent a patch to fix libvirt [1]. The problem is even 
> if this is accepted, our testing branch for libvirt is 2 years behind 
> because they switched to Meson and Osstest has not been adapted to the 
> new build system.
> 
> Anthony kindly offered to update Osstest.
> 
> Regarding force pushing, I am waiting for the Osstest result to confirm 
> that only the libvirt tests are failing in staging (we already have the 
> results for smoke). So my plan is to force push on Monday.
> 
> Please let me know on Monday morning if you have some concerns with this 
> approach.

Actually I do - if we force push, the libvirt failure will stick, and
hence potential further regressions introduced there would not be noticed.

Jan

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Julien Grall]

Hi Jan,

On 29/07/2022 07:22, Jan Beulich wrote:
> On 29.07.2022 03:04, osstest service owner wrote:
>> branch xen-unstable-smoke
>> xenbranch xen-unstable-smoke
>> job build-amd64-libvirt
>> testid libvirt-build
>>
>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>> Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>> Tree: xen git://xenbits.xen.org/xen.git
>>
>> *** Found and reproduced problem changeset ***
>>
>>    Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>    Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>    Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>    Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/171909/
>>
>>
>>    commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>    Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>    Date:   Fri Jul 15 22:20:24 2022 +0300
>>    
>>        libxl: Add support for Virtio disk configuration
> 
> Just in case you didn't notice it: Something's wrong here. I didn't look
> at the details at all. Please advise whether a fix will soon arrive or
> whether we should revert for the time being.

We had discussion on IRC about this today. This is an issue in libvirt 
rather than Xen. So I think a revert is not warrant here.

Instead, it was suggested to force push because it is going to take some 
times to fix libvirt (see more below).

Oleksandr already sent a patch to fix libvirt [1]. The problem is even 
if this is accepted, our testing branch for libvirt is 2 years behind 
because they switched to Meson and Osstest has not been adapted to the 
new build system.

Anthony kindly offered to update Osstest.

Regarding force pushing, I am waiting for the Osstest result to confirm 
that only the libvirt tests are failing in staging (we already have the 
results for smoke). So my plan is to force push on Monday.

Please let me know on Monday morning if you have some concerns with this 
approach.

Cheers,

[1] 
https://lore.kernel.org/xen-devel/20220729155024.3327364-1-olekstysh@gmail.com/
-- 
Julien Grall

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Oleksandr]

On 29.07.22 13:29, Julien Grall wrote:
> Hi Oleksandr,


Hello Julien


>
> On 29/07/2022 11:25, Oleksandr Tyshchenko wrote:
>>
>> On 29.07.22 12:08, Julien Grall wrote:
>>
>>
>> Hello Julien
>>
>>> (+ Anthony)
>>>
>>> Hi,
>>>
>>> On 29/07/2022 07:48, Oleksandr Tyshchenko wrote:
>>>>
>>>> On 29.07.22 09:22, Jan Beulich wrote:
>>>>
>>>> Hello Jan
>>>>
>>>>> On 29.07.2022 03:04, osstest service owner wrote:
>>>>>> branch xen-unstable-smoke
>>>>>> xenbranch xen-unstable-smoke
>>>>>> job build-amd64-libvirt
>>>>>> testid libvirt-build
>>>>>>
>>>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>>>>> Tree: libvirt_keycodemapdb
>>>>>> https://urldefense.com/v3/__https://gitlab.com/keycodemap/keycodemapdb.git__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpzij9yLM$ 
>>>>>>
>>>>>> [gitlab[.]com]
>>>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>>>>> Tree: xen git://xenbits.xen.org/xen.git
>>>>>>
>>>>>> *** Found and reproduced problem changeset ***
>>>>>>
>>>>>>      Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>>>>      Bug introduced: 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>>      Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>>>>      Last fail repro:
>>>>>> https://urldefense.com/v3/__http://logs.test-lab.xenproject.org/osstest/logs/171909/__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpmYABJkc$ 
>>>>>>
>>>>>> [logs[.]test-lab[.]xenproject[.]org]
>>>>>>
>>>>>>
>>>>>>      commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>>      Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>>      Date:   Fri Jul 15 22:20:24 2022 +0300
>>>>>>              libxl: Add support for Virtio disk configuration
>>>>> Just in case you didn't notice it: Something's wrong here. I didn't
>>>>> look
>>>>> at the details at all. Please advise whether a fix will soon 
>>>>> arrive or
>>>>> whether we should revert for the time being.
>>>>
>>>> Sorry for the breakage. At the moment I have no idea what is wrong 
>>>> here,
>>>
>>>  From the build log:
>>>
>>> ../../src/libxl/xen_xl.c: In function 'xenParseXLDisk':
>>> ../../src/libxl/xen_xl.c:779:17: error: enumeration value
>>> 'LIBXL_DISK_BACKEND_STANDALONE' not handled in switch
>>> [-Werror=switch-enum]
>>>                   switch (libxldisk->backend) {
>>>                   ^~~~~~
>>>
>>> The switch contains a default branch [1], so I am a bit puzzled why
>>> GCC is not happy here.
>>
>> Libvirt seems to compiled with -Wswitch-enum
>>
>> And https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says the
>> following:
>>
>> "-Wswitch-enum
>>
>> Warn whenever a switch statement has an index of enumerated type and
>> lacks a case for one or more of the named codes of that enumeration.
>> case labels outside the enumeration range also provoke warnings when
>> this option is used. The only difference between -Wswitch and this
>> option is that this option gives a warning about an omitted enumeration
>> code even if there is a default label."
>
> Thanks for digging! That's explained the error. I still don't think we 
> can solve the error in libxl.
>
> So I would suggest to involve the libvirt folks to know how they want 
> to solve the issue.


Already pushed an immediate fix with detailed description:

https://lore.kernel.org/xen-devel/20220729155024.3327364-1-olekstysh@gmail.com/


>
> Cheers,
>
-- 
Regards,

Oleksandr Tyshchenko

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Julien Grall]

Hi Oleksandr,

On 29/07/2022 11:25, Oleksandr Tyshchenko wrote:
> 
> On 29.07.22 12:08, Julien Grall wrote:
> 
> 
> Hello Julien
> 
>> (+ Anthony)
>>
>> Hi,
>>
>> On 29/07/2022 07:48, Oleksandr Tyshchenko wrote:
>>>
>>> On 29.07.22 09:22, Jan Beulich wrote:
>>>
>>> Hello Jan
>>>
>>>> On 29.07.2022 03:04, osstest service owner wrote:
>>>>> branch xen-unstable-smoke
>>>>> xenbranch xen-unstable-smoke
>>>>> job build-amd64-libvirt
>>>>> testid libvirt-build
>>>>>
>>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>>>> Tree: libvirt_keycodemapdb
>>>>> https://urldefense.com/v3/__https://gitlab.com/keycodemap/keycodemapdb.git__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpzij9yLM$
>>>>> [gitlab[.]com]
>>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>>>> Tree: xen git://xenbits.xen.org/xen.git
>>>>>
>>>>> *** Found and reproduced problem changeset ***
>>>>>
>>>>>      Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>>>      Bug introduced: 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>      Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>>>      Last fail repro:
>>>>> https://urldefense.com/v3/__http://logs.test-lab.xenproject.org/osstest/logs/171909/__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpmYABJkc$
>>>>> [logs[.]test-lab[.]xenproject[.]org]
>>>>>
>>>>>
>>>>>      commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>>      Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>>      Date:   Fri Jul 15 22:20:24 2022 +0300
>>>>>              libxl: Add support for Virtio disk configuration
>>>> Just in case you didn't notice it: Something's wrong here. I didn't
>>>> look
>>>> at the details at all. Please advise whether a fix will soon arrive or
>>>> whether we should revert for the time being.
>>>
>>> Sorry for the breakage. At the moment I have no idea what is wrong here,
>>
>>  From the build log:
>>
>> ../../src/libxl/xen_xl.c: In function 'xenParseXLDisk':
>> ../../src/libxl/xen_xl.c:779:17: error: enumeration value
>> 'LIBXL_DISK_BACKEND_STANDALONE' not handled in switch
>> [-Werror=switch-enum]
>>                   switch (libxldisk->backend) {
>>                   ^~~~~~
>>
>> The switch contains a default branch [1], so I am a bit puzzled why
>> GCC is not happy here.
> 
> Libvirt seems to compiled with -Wswitch-enum
> 
> And https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says the
> following:
> 
> "-Wswitch-enum
> 
> Warn whenever a switch statement has an index of enumerated type and
> lacks a case for one or more of the named codes of that enumeration.
> case labels outside the enumeration range also provoke warnings when
> this option is used. The only difference between -Wswitch and this
> option is that this option gives a warning about an omitted enumeration
> code even if there is a default label."

Thanks for digging! That's explained the error. I still don't think we 
can solve the error in libxl.

So I would suggest to involve the libvirt folks to know how they want to 
solve the issue.

Cheers,

-- 
Julien Grall

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Oleksandr Tyshchenko]

On 29.07.22 12:08, Julien Grall wrote:


Hello Julien

> (+ Anthony)
>
> Hi,
>
> On 29/07/2022 07:48, Oleksandr Tyshchenko wrote:
>>
>> On 29.07.22 09:22, Jan Beulich wrote:
>>
>> Hello Jan
>>
>>> On 29.07.2022 03:04, osstest service owner wrote:
>>>> branch xen-unstable-smoke
>>>> xenbranch xen-unstable-smoke
>>>> job build-amd64-libvirt
>>>> testid libvirt-build
>>>>
>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>>> Tree: libvirt_keycodemapdb 
>>>> https://urldefense.com/v3/__https://gitlab.com/keycodemap/keycodemapdb.git__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpzij9yLM$ 
>>>> [gitlab[.]com]
>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>>> Tree: xen git://xenbits.xen.org/xen.git
>>>>
>>>> *** Found and reproduced problem changeset ***
>>>>
>>>>     Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>>     Bug introduced: 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>     Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>>     Last fail repro: 
>>>> https://urldefense.com/v3/__http://logs.test-lab.xenproject.org/osstest/logs/171909/__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpmYABJkc$ 
>>>> [logs[.]test-lab[.]xenproject[.]org]
>>>>
>>>>
>>>>     commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>     Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>     Date:   Fri Jul 15 22:20:24 2022 +0300
>>>>             libxl: Add support for Virtio disk configuration
>>> Just in case you didn't notice it: Something's wrong here. I didn't 
>>> look
>>> at the details at all. Please advise whether a fix will soon arrive or
>>> whether we should revert for the time being.
>>
>> Sorry for the breakage. At the moment I have no idea what is wrong here,
>
> From the build log:
>
> ../../src/libxl/xen_xl.c: In function 'xenParseXLDisk':
> ../../src/libxl/xen_xl.c:779:17: error: enumeration value 
> 'LIBXL_DISK_BACKEND_STANDALONE' not handled in switch 
> [-Werror=switch-enum]
>                  switch (libxldisk->backend) {
>                  ^~~~~~
>
> The switch contains a default branch [1], so I am a bit puzzled why 
> GCC is not happy here.

Libvirt seems to compiled with -Wswitch-enum

And https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says the 
following:

"-Wswitch-enum

Warn whenever a switch statement has an index of enumerated type and 
lacks a case for one or more of the named codes of that enumeration. 
case labels outside the enumeration range also provoke warnings when 
this option is used. The only difference between -Wswitch and this 
option is that this option gives a warning about an omitted enumeration 
code even if there is a default label."


[snip]

-- 
Regards,

Oleksandr Tyshchenko

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Oleksandr Tyshchenko]

On 29.07.22 12:08, Julien Grall wrote:


Hello Julien

> (+ Anthony)
>
> Hi,
>
> On 29/07/2022 07:48, Oleksandr Tyshchenko wrote:
>>
>> On 29.07.22 09:22, Jan Beulich wrote:
>>
>> Hello Jan
>>
>>> On 29.07.2022 03:04, osstest service owner wrote:
>>>> branch xen-unstable-smoke
>>>> xenbranch xen-unstable-smoke
>>>> job build-amd64-libvirt
>>>> testid libvirt-build
>>>>
>>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>>> Tree: libvirt_keycodemapdb 
>>>> https://urldefense.com/v3/__https://gitlab.com/keycodemap/keycodemapdb.git__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpzij9yLM$ 
>>>> [gitlab[.]com]
>>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>>> Tree: xen git://xenbits.xen.org/xen.git
>>>>
>>>> *** Found and reproduced problem changeset ***
>>>>
>>>>     Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>>     Bug introduced: 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>     Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>>     Last fail repro: 
>>>> https://urldefense.com/v3/__http://logs.test-lab.xenproject.org/osstest/logs/171909/__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpmYABJkc$ 
>>>> [logs[.]test-lab[.]xenproject[.]org]
>>>>
>>>>
>>>>     commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>>     Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>     Date:   Fri Jul 15 22:20:24 2022 +0300
>>>>             libxl: Add support for Virtio disk configuration
>>> Just in case you didn't notice it: Something's wrong here. I didn't 
>>> look
>>> at the details at all. Please advise whether a fix will soon arrive or
>>> whether we should revert for the time being.
>>
>> Sorry for the breakage. At the moment I have no idea what is wrong here,
>
> From the build log:
>
> ../../src/libxl/xen_xl.c: In function 'xenParseXLDisk':
> ../../src/libxl/xen_xl.c:779:17: error: enumeration value 
> 'LIBXL_DISK_BACKEND_STANDALONE' not handled in switch 
> [-Werror=switch-enum]
>                  switch (libxldisk->backend) {
>                  ^~~~~~
>
> The switch contains a default branch [1], so I am a bit puzzled why 
> GCC is not happy here.
>
>>
>> I will try to investigate and provide a fix by the end of the day.
>
> So the general expectation is libvirt should be able to compile 
> without using the new features provided by libxl.
>
> In this case, I am not sure there is anything we could do in libxl 
> without large rework to conditionally define 
> LIBXL_DISK_BACKEND_STANDALONE.
>
> So if a fix is necessary, then it will probably need to be in libvirt.


I haven't even imagined that I would need to build something else except 
xen tools itself to check whether patch series doesn't break anything, 
sorry.

I have just reproduced an issue by building libvirt according to the 
steps in the osstest build log (this was a fun). Except an error being 
reported by test there is one more, almost the similar to reported one, 
in libxlUpdateDiskDef() but there switch doesn't contain a default branch.

With that diff I was able to build w/o issues.

diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 8e63d40376..6745212ae8 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -1219,6 +1219,7 @@ libxlUpdateDiskDef(virDomainDiskDefPtr l_disk, 
libxl_device_disk *x_disk)
          driver = "phy";
          break;
      case LIBXL_DISK_BACKEND_UNKNOWN:
+    case LIBXL_DISK_BACKEND_STANDALONE:
          break;
      }
      if (driver)
diff --git a/src/libxl/xen_xl.c b/src/libxl/xen_xl.c
index f9dc18ab18..a55871bb56 100644
--- a/src/libxl/xen_xl.c
+++ b/src/libxl/xen_xl.c
@@ -796,6 +796,7 @@ xenParseXLDisk(virConfPtr conf, virDomainDefPtr def)
                          goto fail;
                      virDomainDiskSetType(disk, VIR_STORAGE_TYPE_BLOCK);
                      break;
+                case LIBXL_DISK_BACKEND_STANDALONE:
                  default:
                      virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
                                     _("disk backend not supported: %s"),


>
> Cheers,
>
> [1] 
> https://urldefense.com/v3/__https://xenbits.xen.org/gitweb/?p=libvirt.git;a=blob;f=src*libxl*xen_xl.c;h=f9dc18ab18b208d319282ce422f46c75135c0673;hb=refs*heads*xen-tested-master*l779__;Ly8vLyM!!GF_29dbcQIUBPA!2IntpOXH95iBjVgHqZ8H_0-otnI7PwzKbLVSf6Dg3vsyxkrQOiJQPjPSqJliGoPuaf1JXmszMlKloTcFUDYBOA$ 
> [xenbits[.]xen[.]org]
>
-- 
Regards,

Oleksandr Tyshchenko

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Julien Grall]

(+ Anthony)

Hi,

On 29/07/2022 07:48, Oleksandr Tyshchenko wrote:
> 
> On 29.07.22 09:22, Jan Beulich wrote:
> 
> Hello Jan
> 
>> On 29.07.2022 03:04, osstest service owner wrote:
>>> branch xen-unstable-smoke
>>> xenbranch xen-unstable-smoke
>>> job build-amd64-libvirt
>>> testid libvirt-build
>>>
>>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>>> Tree: libvirt_keycodemapdb https://urldefense.com/v3/__https://gitlab.com/keycodemap/keycodemapdb.git__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpzij9yLM$ [gitlab[.]com]
>>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>>> Tree: xen git://xenbits.xen.org/xen.git
>>>
>>> *** Found and reproduced problem changeset ***
>>>
>>>     Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>>     Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>     Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>>     Last fail repro: https://urldefense.com/v3/__http://logs.test-lab.xenproject.org/osstest/logs/171909/__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpmYABJkc$ [logs[.]test-lab[.]xenproject[.]org]
>>>
>>>
>>>     commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>>     Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>     Date:   Fri Jul 15 22:20:24 2022 +0300
>>>     
>>>         libxl: Add support for Virtio disk configuration
>> Just in case you didn't notice it: Something's wrong here. I didn't look
>> at the details at all. Please advise whether a fix will soon arrive or
>> whether we should revert for the time being.
> 
> Sorry for the breakage. At the moment I have no idea what is wrong here,

 From the build log:

../../src/libxl/xen_xl.c: In function 'xenParseXLDisk':
../../src/libxl/xen_xl.c:779:17: error: enumeration value 
'LIBXL_DISK_BACKEND_STANDALONE' not handled in switch [-Werror=switch-enum]
                  switch (libxldisk->backend) {
                  ^~~~~~

The switch contains a default branch [1], so I am a bit puzzled why GCC 
is not happy here.

> 
> I will try to investigate and provide a fix by the end of the day.

So the general expectation is libvirt should be able to compile without 
using the new features provided by libxl.

In this case, I am not sure there is anything we could do in libxl 
without large rework to conditionally define LIBXL_DISK_BACKEND_STANDALONE.

So if a fix is necessary, then it will probably need to be in libvirt.

Cheers,

[1] 
https://xenbits.xen.org/gitweb/?p=libvirt.git;a=blob;f=src/libxl/xen_xl.c;h=f9dc18ab18b208d319282ce422f46c75135c0673;hb=refs/heads/xen-tested-master#l779

-- 
Julien Grall

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Oleksandr Tyshchenko]

On 29.07.22 09:22, Jan Beulich wrote:

Hello Jan

> On 29.07.2022 03:04, osstest service owner wrote:
>> branch xen-unstable-smoke
>> xenbranch xen-unstable-smoke
>> job build-amd64-libvirt
>> testid libvirt-build
>>
>> Tree: libvirt git://xenbits.xen.org/libvirt.git
>> Tree: libvirt_keycodemapdb https://urldefense.com/v3/__https://gitlab.com/keycodemap/keycodemapdb.git__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpzij9yLM$ [gitlab[.]com]
>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>> Tree: xen git://xenbits.xen.org/xen.git
>>
>> *** Found and reproduced problem changeset ***
>>
>>    Bug is in tree:  xen git://xenbits.xen.org/xen.git
>>    Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>    Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>>    Last fail repro: https://urldefense.com/v3/__http://logs.test-lab.xenproject.org/osstest/logs/171909/__;!!GF_29dbcQIUBPA!0s_nyAgds977dw0dGPgFJGkIaBiKiXH3nR11Ni6gGjN5gQmB0DEhKrm5SUX4R0WhK8YkQemR6RVhiojpmYABJkc$ [logs[.]test-lab[.]xenproject[.]org]
>>
>>
>>    commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>>    Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>    Date:   Fri Jul 15 22:20:24 2022 +0300
>>    
>>        libxl: Add support for Virtio disk configuration
> Just in case you didn't notice it: Something's wrong here. I didn't look
> at the details at all. Please advise whether a fix will soon arrive or
> whether we should revert for the time being.

Sorry for the breakage. At the moment I have no idea what is wrong here,

I will try to investigate and provide a fix by the end of the day.


>
> Jan

-- 
Regards,

Oleksandr Tyshchenko

Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt

[Jan Beulich]

On 29.07.2022 03:04, osstest service owner wrote:
> branch xen-unstable-smoke
> xenbranch xen-unstable-smoke
> job build-amd64-libvirt
> testid libvirt-build
> 
> Tree: libvirt git://xenbits.xen.org/libvirt.git
> Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>   Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/171909/
> 
> 
>   commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
>   Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>   Date:   Fri Jul 15 22:20:24 2022 +0300
>   
>       libxl: Add support for Virtio disk configuration

Just in case you didn't notice it: Something's wrong here. I didn't look
at the details at all. Please advise whether a fix will soon arrive or
whether we should revert for the time being.

Jan

[xen-unstable-smoke bisection] complete build-amd64-libvirt

[osstest service owner]

branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64-libvirt
testid libvirt-build

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
  Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/171909/


  commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
  Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
  Date:   Fri Jul 15 22:20:24 2022 +0300
  
      libxl: Add support for Virtio disk configuration
      
      This patch adds basic support for configuring and assisting virtio-mmio
      based virtio-disk backend (emulator) which is intended to run out of
      Qemu and could be run in any domain.
      Although the Virtio block device is quite different from traditional
      Xen PV block device (vbd) from the toolstack's point of view:
       - as the frontend is virtio-blk which is not a Xenbus driver, nothing
         written to Xenstore are fetched by the frontend currently ("vdev"
         is not passed to the frontend). But this might need to be revised
         in future, so frontend data might be written to Xenstore in order to
         support hotplugging virtio devices or passing the backend domain id
         on arch where the device-tree is not available.
       - the ring-ref/event-channel are not used for the backend<->frontend
         communication, the proposed IPC for Virtio is IOREQ/DM
      it is still a "block device" and ought to be integrated in existing
      "disk" handling. So, re-use (and adapt) "disk" parsing/configuration
      logic to deal with Virtio devices as well.
      
      For the immediate purpose and an ability to extend that support for
      other use-cases in future (Qemu, virtio-pci, etc) perform the following
      actions:
      - Add new disk backend type (LIBXL_DISK_BACKEND_STANDALONE) and reflect
        that in the configuration
      - Introduce new disk "specification" and "transport" fields to struct
        libxl_device_disk. Both are written to the Xenstore. The transport
        field is only used for the specification "virtio" and it assumes
        only "mmio" value for now.
      - Introduce new "specification" option with "xen" communication
        protocol being default value.
      - Add new device kind (LIBXL__DEVICE_KIND_VIRTIO_DISK) as current
        one (LIBXL__DEVICE_KIND_VBD) doesn't fit into Virtio disk model
      
      An example of domain configuration for Virtio disk:
      disk = [ 'phy:/dev/mmcblk0p3, xvda1, backendtype=standalone, specification=virtio']
      
      Nothing has changed for default Xen disk configuration.
      
      Please note, this patch is not enough for virtio-disk to work
      on Xen (Arm), as for every Virtio device (including disk) we need
      to allocate Virtio MMIO params (IRQ and memory region) and pass
      them to the backend, also update Guest device-tree. The subsequent
      patch will add these missing bits. For the current patch,
      the default "irq" and "base" are just written to the Xenstore.
      This is not an ideal splitting, but this way we avoid breaking
      the bisectability.
      
      Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
      Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
      Acked-by: George Dunlap <george.dunlap@citrix.com>
      Tested-by: Jiamei Xie <jiamei.xie@arm.com>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64-libvirt.libvirt-build --summary-out=tmp/171909.bisection-summary --basis-template=171884 --blessings=real,real-bisect,real-retry xen-unstable-smoke build-amd64-libvirt libvirt-build
Searching for failure / basis pass:
 171899 fail [host=himrod1] / 171884 ok.
Failure / basis pass flights: 171899 / 171884
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 ca45d3cb4586372909f350e54482246f994e1bc7
Basis pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/libvirt.git#2c846fa6bcc11929c9fb857a22430fb9945654ad-2c846fa6bcc11929c9fb857a22430fb9945654ad https://gitlab.com/keycodemap/keycodemapdb.git#27acf0ef828bf719b2053ba398b195829413dbdd-27acf0ef828bf719b2053ba398b195829413dbdd git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#b746458e1ce1bec85e58b458386f8b7a0bedf\
 aa6-b746458e1ce1bec85e58b458386f8b7a0bedfaa6 git://xenbits.xen.org/xen.git#f732240fd3bac25116151db5ddeb7203b62e85ce-ca45d3cb4586372909f350e54482246f994e1bc7
Loaded 5001 nodes in revision graph
Searching for test results:
 171884 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
 171909 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
 171899 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 ca45d3cb4586372909f350e54482246f994e1bc7
 171902 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
 171904 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 ca45d3cb4586372909f350e54482246f994e1bc7
 171905 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
 171906 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
 171907 fail 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
 171908 pass 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
Searching for interesting versions
 Result found: flight 171884 (pass), for basis pass
 For basis failure, parent search stopping at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce, results HASH(0x557af26f7d68) HASH(0x557af2703340) HASH(0x557af2707f78) HASH(0x557af270bb08) Result found: flight 171899 (fail), for basis failure (at ancestor ~368)
 Repro found: flight 171902 (pass), for basis pass
 Repro found: flight 171904 (fail), for basis failure
 0 revisions at 2c846fa6bcc11929c9fb857a22430fb9945654ad 27acf0ef828bf719b2053ba398b195829413dbdd 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 f732240fd3bac25116151db5ddeb7203b62e85ce
No revisions left to test, checking graph state.
 Result found: flight 171884 (pass), for last pass
 Result found: flight 171905 (fail), for first failure
 Repro found: flight 171906 (pass), for last pass
 Repro found: flight 171907 (fail), for first failure
 Repro found: flight 171908 (pass), for last pass
 Repro found: flight 171909 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  66dd1c62b2a3c707bd5c55750d10a8223fbd577f
  Bug not present: f732240fd3bac25116151db5ddeb7203b62e85ce
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/171909/


  commit 66dd1c62b2a3c707bd5c55750d10a8223fbd577f
  Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
  Date:   Fri Jul 15 22:20:24 2022 +0300
  
      libxl: Add support for Virtio disk configuration
      
      This patch adds basic support for configuring and assisting virtio-mmio
      based virtio-disk backend (emulator) which is intended to run out of
      Qemu and could be run in any domain.
      Although the Virtio block device is quite different from traditional
      Xen PV block device (vbd) from the toolstack's point of view:
       - as the frontend is virtio-blk which is not a Xenbus driver, nothing
         written to Xenstore are fetched by the frontend currently ("vdev"
         is not passed to the frontend). But this might need to be revised
         in future, so frontend data might be written to Xenstore in order to
         support hotplugging virtio devices or passing the backend domain id
         on arch where the device-tree is not available.
       - the ring-ref/event-channel are not used for the backend<->frontend
         communication, the proposed IPC for Virtio is IOREQ/DM
      it is still a "block device" and ought to be integrated in existing
      "disk" handling. So, re-use (and adapt) "disk" parsing/configuration
      logic to deal with Virtio devices as well.
      
      For the immediate purpose and an ability to extend that support for
      other use-cases in future (Qemu, virtio-pci, etc) perform the following
      actions:
      - Add new disk backend type (LIBXL_DISK_BACKEND_STANDALONE) and reflect
        that in the configuration
      - Introduce new disk "specification" and "transport" fields to struct
        libxl_device_disk. Both are written to the Xenstore. The transport
        field is only used for the specification "virtio" and it assumes
        only "mmio" value for now.
      - Introduce new "specification" option with "xen" communication
        protocol being default value.
      - Add new device kind (LIBXL__DEVICE_KIND_VIRTIO_DISK) as current
        one (LIBXL__DEVICE_KIND_VBD) doesn't fit into Virtio disk model
      
      An example of domain configuration for Virtio disk:
      disk = [ 'phy:/dev/mmcblk0p3, xvda1, backendtype=standalone, specification=virtio']
      
      Nothing has changed for default Xen disk configuration.
      
      Please note, this patch is not enough for virtio-disk to work
      on Xen (Arm), as for every Virtio device (including disk) we need
      to allocate Virtio MMIO params (IRQ and memory region) and pass
      them to the backend, also update Guest device-tree. The subsequent
      patch will add these missing bits. For the current patch,
      the default "irq" and "base" are just written to the Xenstore.
      This is not an ideal splitting, but this way we avoid breaking
      the bisectability.
      
      Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
      Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
      Acked-by: George Dunlap <george.dunlap@citrix.com>
      Tested-by: Jiamei Xie <jiamei.xie@arm.com>

Revision graph left in /home/logs/results/bisect/xen-unstable-smoke/build-amd64-libvirt.libvirt-build.{dot,ps,png,html,svg}.
----------------------------------------
171909: tolerable ALL FAIL

flight 171909 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/171909/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-amd64-libvirt           6 libvirt-build           fail baseline untested


jobs:
 build-amd64-libvirt                                          fail    


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