* [xen-unstable-smoke test] 161321: regressions - FAIL
@ 2021-04-20 14:37 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2021-04-20 14:37 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 161321 xen-unstable-smoke real [real]
flight 161328 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161321/
http://logs.test-lab.xenproject.org/osstest/logs/161328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 18 guest-localmigrate/x10 fail REGR. vs. 161293
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass
test-armhf-armhf-xl 15 migrate-support-check fail never pass
test-armhf-armhf-xl 16 saverestore-support-check fail never pass
version targeted for testing:
xen 730d0f6082e66eefae64f35bc62e51fc54d02d55
baseline version:
xen a8c532be6a44c7faa54ac777a717f4aa65e3a806
Last test of basis 161293 2021-04-19 14:00:26 Z 1 days
Testing same since 161321 2021-04-20 10:02:00 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@suse.com>
Roger Pau Monné <roger.pau@citrix.com>
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail
test-amd64-amd64-libvirt pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 730d0f6082e66eefae64f35bc62e51fc54d02d55
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Tue Apr 20 11:36:54 2021 +0200
x86/dpci: remove the dpci EOI timer
Current interrupt pass though code will setup a timer for each
interrupt injected to the guest that requires an EOI from the guest.
Such timer would perform two actions if the guest doesn't EOI the
interrupt before a given period of time. The first one is deasserting
the virtual line, the second is perform an EOI of the physical
interrupt source if it requires such.
The deasserting of the guest virtual line is wrong, since it messes
with the interrupt status of the guest. This seems to have been done
in order to compensate for missing deasserts when certain interrupt
controller actions are performed. The original motivation of the
introduction of the timer was to fix issues when a GSI was shared
between different guests. We believe that other changes in the
interrupt handling code (ie: proper propagation of EOI related actions
to dpci) will have fixed such errors now.
Performing an EOI of the physical interrupt source is redundant, since
there's already a timer that takes care of this for all interrupts,
not just the HVM dpci ones, see irq_guest_action_t struct eoi_timer
field.
Since both of the actions performed by the dpci timer are not
required, remove it altogether.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 2d494f2198d7909a394085d079475bb099d7afe7
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Tue Apr 20 11:36:09 2021 +0200
x86/vpic: issue dpci EOI for cleared pins at ICW1
When pins are cleared from either ISR or IRR as part of the
initialization sequence forward the clearing of those pins to the dpci
EOI handler, as it is equivalent to an EOI. Not doing so can bring the
interrupt controller state out of sync with the dpci handling logic,
that expects a notification when a pin has been EOI'ed.
Fixes: 7b3cb5e5416 ('IRQ injection changes for HVM PCI passthru.')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 192f7479f21ef63dad8d8acbbda93cce0971fe66
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Tue Apr 20 11:35:29 2021 +0200
x86/vpic: don't trigger unmask event until end of init
Wait until the end of the init sequence to trigger the unmask event.
Note that it will be unconditionally triggered, but that's harmless if
not unmask actually happened.
While there change the variable type to bool.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit 1ca901c527d21c083ceb706839db2cdac102926c
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Tue Apr 20 11:34:53 2021 +0200
x86/vpic: force int output to low when in init mode
When the PIC is on the init sequence prevent interrupt delivery. The
state of the registers is in the process of being set during the init
phase, so it makes sense to prevent any int line changes during that
process.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
(qemu changes not included)
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-04-20 14:37 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-20 14:37 [xen-unstable-smoke test] 161321: regressions - FAIL osstest service owner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).