[xen-4.13-testing bisection] complete test-xtf-amd64-amd64-4

2020-09-26 Thread osstest service owner 
branch xen-4.13-testing
xenbranch xen-4.13-testing
job test-xtf-amd64-amd64-4
testid xtf/test-pv64-xsa-221

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Tree: xtf git://xenbits.xen.org/xtf.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  e1364e05f92d6c2f12cc77f100cea584354c66cb
  Bug not present: 5867a14ac1747d7411066d7fb2cf238658346ab0
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/154848/


  commit e1364e05f92d6c2f12cc77f100cea584354c66cb
  Author: Jan Beulich 
  Date:   Tue Sep 22 16:24:29 2020 +0200
  
  evtchn/x86: enforce correct upper limit for 32-bit guests
  
  The recording of d->max_evtchns in evtchn_2l_init(), in particular with
  the limited set of callers of the function, is insufficient. Neither for
  PV nor for HVM guests the bitness is known at domain_create() time, yet
  the upper bound in 2-level mode depends upon guest bitness. Recording
  too high a limit "allows" x86 32-bit domains to open not properly usable
  event channels, management of which (inside Xen) would then result in
  corruption of the shared info and vCPU info structures.
  
  Keep the upper limit dynamic for the 2-level case, introducing a helper
  function to retrieve the effective limit. This helper is now supposed to
  be private to the event channel code. The used in do_poll() and
  domain_dump_evtchn_info() weren't consistent with port uses elsewhere
  and hence get switched to port_is_valid().
  
  Furthermore FIFO mode's setup_ports() gets adjusted to loop only up to
  the prior ABI limit, rather than all the way up to the new one.
  
  Finally a word on the change to do_poll(): Accessing ->max_evtchns
  without holding a suitable lock was never safe, as it as well as
  ->evtchn_port_ops may change behind do_poll()'s back. Using
  port_is_valid() instead widens some the window for potential abuse,
  until we've dealt with the race altogether (see XSA-343).
  
  This is XSA-342.
  
  Reported-by: Julien Grall 
  Fixes: 48974e6ce52e ("evtchn: use a per-domain variable for the max 
number of event channels")
  Signed-off-by: Jan Beulich 
  Reviewed-by: Stefano Stabellini 
  Reviewed-by: Julien Grall 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.13-testing/test-xtf-amd64-amd64-4.xtf--test-pv64-xsa-221.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.13-testing/test-xtf-amd64-amd64-4.xtf--test-pv64-xsa-221
 --summary-out=tmp/154938.bisection-summary --basis-template=154358 
--blessings=real,real-bisect --flight=154938 xen-4.13-testing 
test-xtf-amd64-amd64-4 xtf/test-pv64-xsa-221
Searching for failure / basis pass:
 154667 fail [host=huxelrebe1] / 154602 [host=albana0] 154358 [host=godello0] 
152528 [host=godello0] 151712 [host=elbling1] 151337 [host=albana0] 151153 
[host=godello1] 151048 [host=pinot0] 150944 ok.
Failure / basis pass flights: 154667 / 150944
(tree with no url: minios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Tree: xtf git://xenbits.xen.org/xtf.git
Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
fb97626fe04747ec89599dce0992def9a36e2f6b 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
730e2b1927e7d911bbd5350714054ddd5912f4ed 
155821a1990b6de78dde5f98fa5ab90e802021e0 
88f5b414ac0f8008c1e2b26f93c3d980120941f7 
17d372b763cb0b2e2e6b5a637c11f3997d2533fa
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
6ff7c838d09224dd4e4c9b5b93152d8db1b19740 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
730e2b1927e7d911bbd5350714054ddd5912f4ed 
2e3de6253422112ae43e608661ba94ea6b345694 
67958a166f6b019e5ad8dcd60a96dcd262669092 
2a8859e87761a0efc119778e094f203dc2ea487a
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://

[xen-4.13-testing bisection] complete test-xtf-amd64-amd64-4

2020-09-25 Thread osstest service owner 
branch xen-4.13-testing
xenbranch xen-4.13-testing
job test-xtf-amd64-amd64-4
testid xtf/test-hvm64-xsa-221

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Tree: xtf git://xenbits.xen.org/xtf.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  e1364e05f92d6c2f12cc77f100cea584354c66cb
  Bug not present: 5867a14ac1747d7411066d7fb2cf238658346ab0
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/154848/


  commit e1364e05f92d6c2f12cc77f100cea584354c66cb
  Author: Jan Beulich 
  Date:   Tue Sep 22 16:24:29 2020 +0200
  
  evtchn/x86: enforce correct upper limit for 32-bit guests
  
  The recording of d->max_evtchns in evtchn_2l_init(), in particular with
  the limited set of callers of the function, is insufficient. Neither for
  PV nor for HVM guests the bitness is known at domain_create() time, yet
  the upper bound in 2-level mode depends upon guest bitness. Recording
  too high a limit "allows" x86 32-bit domains to open not properly usable
  event channels, management of which (inside Xen) would then result in
  corruption of the shared info and vCPU info structures.
  
  Keep the upper limit dynamic for the 2-level case, introducing a helper
  function to retrieve the effective limit. This helper is now supposed to
  be private to the event channel code. The used in do_poll() and
  domain_dump_evtchn_info() weren't consistent with port uses elsewhere
  and hence get switched to port_is_valid().
  
  Furthermore FIFO mode's setup_ports() gets adjusted to loop only up to
  the prior ABI limit, rather than all the way up to the new one.
  
  Finally a word on the change to do_poll(): Accessing ->max_evtchns
  without holding a suitable lock was never safe, as it as well as
  ->evtchn_port_ops may change behind do_poll()'s back. Using
  port_is_valid() instead widens some the window for potential abuse,
  until we've dealt with the race altogether (see XSA-343).
  
  This is XSA-342.
  
  Reported-by: Julien Grall 
  Fixes: 48974e6ce52e ("evtchn: use a per-domain variable for the max 
number of event channels")
  Signed-off-by: Jan Beulich 
  Reviewed-by: Stefano Stabellini 
  Reviewed-by: Julien Grall 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.13-testing/test-xtf-amd64-amd64-4.xtf--test-hvm64-xsa-221.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.13-testing/test-xtf-amd64-amd64-4.xtf--test-hvm64-xsa-221
 --summary-out=tmp/154848.bisection-summary --basis-template=154358 
--blessings=real,real-bisect xen-4.13-testing test-xtf-amd64-amd64-4 
xtf/test-hvm64-xsa-221
Searching for failure / basis pass:
 154667 fail [host=huxelrebe1] / 154602 [host=albana0] 154358 [host=godello0] 
152528 [host=godello0] 151712 [host=elbling1] 151337 [host=albana0] 151153 
[host=godello1] 151048 [host=pinot0] 150944 ok.
Failure / basis pass flights: 154667 / 150944
(tree with no url: minios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Tree: xtf git://xenbits.xen.org/xtf.git
Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
fb97626fe04747ec89599dce0992def9a36e2f6b 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
730e2b1927e7d911bbd5350714054ddd5912f4ed 
155821a1990b6de78dde5f98fa5ab90e802021e0 
88f5b414ac0f8008c1e2b26f93c3d980120941f7 
17d372b763cb0b2e2e6b5a637c11f3997d2533fa
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
6ff7c838d09224dd4e4c9b5b93152d8db1b19740 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
730e2b1927e7d911bbd5350714054ddd5912f4ed 
2e3de6253422112ae43e608661ba94ea6b345694 
67958a166f6b019e5ad8dcd60a96dcd262669092 
2a8859e87761a0efc119778e094f203dc2ea487a
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.