* [xen-unstable-smoke bisection] complete build-amd64-libvirt
@ 2022-07-29 1:04 osstest service owner
2022-07-29 6:22 ` Jan Beulich
0 siblings, 1 reply; 22+ messages in thread
From: osstest service owner @ 2022-07-29 1:04 UTC (permalink / raw)
To: xen-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-07-29 1:04 [xen-unstable-smoke bisection] complete build-amd64-libvirt osstest service owner
@ 2022-07-29 6:22 ` Jan Beulich
2022-07-29 6:48 ` Oleksandr Tyshchenko
2022-07-29 17:36 ` Julien Grall
0 siblings, 2 replies; 22+ messages in thread
From: Jan Beulich @ 2022-07-29 6:22 UTC (permalink / raw)
To: Oleksandr Tyshchenko; +Cc: osstest service owner, xen-devel, Julien Grall
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-07-29 6:22 ` Jan Beulich
@ 2022-07-29 6:48 ` Oleksandr Tyshchenko
2022-07-29 9:08 ` Julien Grall
2022-07-29 17:36 ` Julien Grall
1 sibling, 1 reply; 22+ messages in thread
From: Oleksandr Tyshchenko @ 2022-07-29 6:48 UTC (permalink / raw)
To: Jan Beulich; +Cc: osstest service owner, xen-devel, Julien Grall
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-07-29 6:48 ` Oleksandr Tyshchenko
@ 2022-07-29 9:08 ` Julien Grall
2022-07-29 9:22 ` Oleksandr Tyshchenko
2022-07-29 10:25 ` Oleksandr Tyshchenko
0 siblings, 2 replies; 22+ messages in thread
From: Julien Grall @ 2022-07-29 9:08 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: osstest service owner, xen-devel, Anthony PERARD, Jan Beulich
(+ 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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-07-29 9:08 ` Julien Grall
@ 2022-07-29 9:22 ` Oleksandr Tyshchenko
2022-07-29 10:25 ` Oleksandr Tyshchenko
1 sibling, 0 replies; 22+ messages in thread
From: Oleksandr Tyshchenko @ 2022-07-29 9:22 UTC (permalink / raw)
To: Julien Grall
Cc: osstest service owner, xen-devel, Anthony PERARD, Jan Beulich
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
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-07-29 9:08 ` Julien Grall
2022-07-29 9:22 ` Oleksandr Tyshchenko
@ 2022-07-29 10:25 ` Oleksandr Tyshchenko
2022-07-29 10:29 ` Julien Grall
1 sibling, 1 reply; 22+ messages in thread
From: Oleksandr Tyshchenko @ 2022-07-29 10:25 UTC (permalink / raw)
To: Julien Grall
Cc: osstest service owner, xen-devel, Anthony PERARD, Jan Beulich
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-07-29 10:25 ` Oleksandr Tyshchenko
@ 2022-07-29 10:29 ` Julien Grall
2022-07-29 15:55 ` Oleksandr
0 siblings, 1 reply; 22+ messages in thread
From: Julien Grall @ 2022-07-29 10:29 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: osstest service owner, xen-devel, Anthony PERARD, Jan Beulich
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-07-29 10:29 ` Julien Grall
@ 2022-07-29 15:55 ` Oleksandr
0 siblings, 0 replies; 22+ messages in thread
From: Oleksandr @ 2022-07-29 15:55 UTC (permalink / raw)
To: Julien Grall
Cc: osstest service owner, xen-devel, Anthony PERARD, Jan Beulich,
Oleksandr Tyshchenko
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-07-29 6:22 ` Jan Beulich
2022-07-29 6:48 ` Oleksandr Tyshchenko
@ 2022-07-29 17:36 ` Julien Grall
2022-08-01 8:36 ` Jan Beulich
1 sibling, 1 reply; 22+ messages in thread
From: Julien Grall @ 2022-07-29 17:36 UTC (permalink / raw)
To: Jan Beulich, Oleksandr Tyshchenko, Anthony PERARD
Cc: osstest service owner, xen-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-07-29 17:36 ` Julien Grall
@ 2022-08-01 8:36 ` Jan Beulich
2022-08-01 8:43 ` Julien Grall
0 siblings, 1 reply; 22+ messages in thread
From: Jan Beulich @ 2022-08-01 8:36 UTC (permalink / raw)
To: Julien Grall
Cc: osstest service owner, xen-devel, Oleksandr Tyshchenko, Anthony PERARD
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-08-01 8:36 ` Jan Beulich
@ 2022-08-01 8:43 ` Julien Grall
2022-08-01 9:06 ` Jan Beulich
2022-08-01 13:15 ` Andrew Cooper
0 siblings, 2 replies; 22+ messages in thread
From: Julien Grall @ 2022-08-01 8:43 UTC (permalink / raw)
To: Jan Beulich
Cc: osstest service owner, xen-devel, Oleksandr Tyshchenko,
Anthony PERARD, committers
(+ 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-08-01 8:43 ` Julien Grall
@ 2022-08-01 9:06 ` Jan Beulich
2022-08-01 9:38 ` Julien Grall
2022-08-01 13:15 ` Andrew Cooper
1 sibling, 1 reply; 22+ messages in thread
From: Jan Beulich @ 2022-08-01 9:06 UTC (permalink / raw)
To: Julien Grall
Cc: osstest service owner, xen-devel, Oleksandr Tyshchenko,
Anthony PERARD, committers
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-08-01 9:06 ` Jan Beulich
@ 2022-08-01 9:38 ` Julien Grall
2022-08-02 1:02 ` Henry Wang
0 siblings, 1 reply; 22+ messages in thread
From: Julien Grall @ 2022-08-01 9:38 UTC (permalink / raw)
To: Jan Beulich
Cc: osstest service owner, xen-devel, Oleksandr Tyshchenko,
Anthony PERARD, committers, Henry Wang
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-08-01 9:38 ` Julien Grall
@ 2022-08-02 1:02 ` Henry Wang
0 siblings, 0 replies; 22+ messages in thread
From: Henry Wang @ 2022-08-02 1:02 UTC (permalink / raw)
To: Julien Grall, Jan Beulich
Cc: osstest service owner, xen-devel, Oleksandr Tyshchenko,
Anthony PERARD, committers
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-08-01 8:43 ` Julien Grall
2022-08-01 9:06 ` Jan Beulich
@ 2022-08-01 13:15 ` Andrew Cooper
2022-08-02 10:58 ` Julien Grall
1 sibling, 1 reply; 22+ messages in thread
From: Andrew Cooper @ 2022-08-01 13:15 UTC (permalink / raw)
To: Julien Grall, Jan Beulich
Cc: osstest service owner, xen-devel, Oleksandr Tyshchenko,
Anthony Perard, committers
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-08-01 13:15 ` Andrew Cooper
@ 2022-08-02 10:58 ` Julien Grall
2022-08-04 16:37 ` Julien Grall
0 siblings, 1 reply; 22+ messages in thread
From: Julien Grall @ 2022-08-02 10:58 UTC (permalink / raw)
To: Andrew Cooper, Jan Beulich
Cc: osstest service owner, xen-devel, Oleksandr Tyshchenko,
Anthony Perard, committers
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2022-08-02 10:58 ` Julien Grall
@ 2022-08-04 16:37 ` Julien Grall
0 siblings, 0 replies; 22+ messages in thread
From: Julien Grall @ 2022-08-04 16:37 UTC (permalink / raw)
To: Andrew Cooper, Jan Beulich
Cc: osstest service owner, xen-devel, Oleksandr Tyshchenko,
Anthony Perard, committers
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [xen-unstable-smoke bisection] complete build-amd64-libvirt
@ 2020-12-16 2:27 osstest service owner
2020-12-16 10:17 ` Andrew Cooper
0 siblings, 1 reply; 22+ messages in thread
From: osstest service owner @ 2020-12-16 2:27 UTC (permalink / raw)
To: xen-devel, osstest-admin
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2020-12-16 2:27 osstest service owner
@ 2020-12-16 10:17 ` Andrew Cooper
2020-12-16 10:43 ` Wei Liu
0 siblings, 1 reply; 22+ messages in thread
From: Andrew Cooper @ 2020-12-16 10:17 UTC (permalink / raw)
To: osstest service owner, xen-devel, Paul Durrant, Wei Liu
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2020-12-16 10:17 ` Andrew Cooper
@ 2020-12-16 10:43 ` Wei Liu
2020-12-16 18:04 ` Wei Liu
2020-12-17 8:29 ` Paul Durrant
0 siblings, 2 replies; 22+ messages in thread
From: Wei Liu @ 2020-12-16 10:43 UTC (permalink / raw)
To: Andrew Cooper, Paul Durrant
Cc: osstest service owner, xen-devel, Paul Durrant, 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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2020-12-16 10:43 ` Wei Liu
@ 2020-12-16 18:04 ` Wei Liu
2020-12-17 8:29 ` Paul Durrant
1 sibling, 0 replies; 22+ messages in thread
From: Wei Liu @ 2020-12-16 18:04 UTC (permalink / raw)
To: Andrew Cooper, Paul Durrant; +Cc: osstest service owner, xen-devel, 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [xen-unstable-smoke bisection] complete build-amd64-libvirt
2020-12-16 10:43 ` Wei Liu
2020-12-16 18:04 ` Wei Liu
@ 2020-12-17 8:29 ` Paul Durrant
1 sibling, 0 replies; 22+ messages in thread
From: Paul Durrant @ 2020-12-17 8:29 UTC (permalink / raw)
To: 'Wei Liu', 'Andrew Cooper'
Cc: 'osstest service owner', xen-devel
> -----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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2022-08-04 16:38 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-29 1:04 [xen-unstable-smoke bisection] complete build-amd64-libvirt osstest service owner
2022-07-29 6:22 ` Jan Beulich
2022-07-29 6:48 ` Oleksandr Tyshchenko
2022-07-29 9:08 ` Julien Grall
2022-07-29 9:22 ` Oleksandr Tyshchenko
2022-07-29 10:25 ` Oleksandr Tyshchenko
2022-07-29 10:29 ` Julien Grall
2022-07-29 15:55 ` Oleksandr
2022-07-29 17:36 ` Julien Grall
2022-08-01 8:36 ` Jan Beulich
2022-08-01 8:43 ` Julien Grall
2022-08-01 9:06 ` Jan Beulich
2022-08-01 9:38 ` Julien Grall
2022-08-02 1:02 ` Henry Wang
2022-08-01 13:15 ` Andrew Cooper
2022-08-02 10:58 ` Julien Grall
2022-08-04 16:37 ` Julien Grall
-- strict thread matches above, loose matches on Subject: below --
2020-12-16 2:27 osstest service owner
2020-12-16 10:17 ` Andrew Cooper
2020-12-16 10:43 ` Wei Liu
2020-12-16 18:04 ` Wei Liu
2020-12-17 8:29 ` Paul Durrant
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.