|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 156642: regressions - FAIL
flight 156642 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/156642/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-build fail REGR. vs. 156622 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a 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 628e1becb6fb121475a6ce68e3f1cb4499851255 baseline version: xen 3059178798a23ba870ff86ff54d442a07e6651fc Last test of basis 156622 2020-11-10 13:01:19 Z 0 days Failing since 156628 2020-11-10 17:00:28 Z 0 days 2 attempts Testing same since 156642 2020-11-10 20:00:30 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Juergen Gross <jgross@xxxxxxxx> Julien Grall <jgrall@xxxxxxxxxx> jobs: build-arm64-xsm pass build-amd64 fail build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-libvirt blocked ------------------------------------------------------------ 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 628e1becb6fb121475a6ce68e3f1cb4499851255 Author: Julien Grall <jgrall@xxxxxxxxxx> Date: Mon Nov 9 20:28:59 2020 +0000 xen/arm: Always trap AMU system registers The Activity Monitors Unit (AMU) has been introduced by ARMv8.4. It is considered to be unsafe to be expose to guests as they might expose information about code executed by other guests or the host. Arm provided a way to trap all the AMU system registers by setting CPTR_EL2.TAM to 1. Unfortunately, on older revision of the specification, the bit 30 (now CPTR_EL1.TAM) was RES0. Because of that, Xen is setting it to 0 and therefore the system registers would be exposed to the guest when it is run on processors with AMU. As the bit is mark as UNKNOWN at boot in Armv8.4, the only safe solution for us is to always set CPTR_EL1.TAM to 1. Guest trying to access the AMU system registers will now receive an undefined instruction. Unfortunately, this means that even well-behaved guest may fail to boot because we don't sanitize the ID registers. This is a known issues with other Armv8.0+ features (e.g. SVE, Pointer Auth). This will taken care separately. This is part of XSA-351 (or XSA-93 re-born). Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx> Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx> commit e6e85b662be9eab96f4cfc58e9945580cce8b2bb Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Nov 10 14:40:09 2020 +0100 x86/CPUID: also check leaf 7 max subleaf to be compatible Just like is done for basic and extended major leaves. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit f5cfa09856732b1d78ff6a21ca3dc33a010da951 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Nov 10 14:39:30 2020 +0100 x86/CPUID: suppress IOMMU related hypervisor leaf data Now that the IOMMU for guests can't be enabled "on demand" anymore, there's also no reason to expose the related CPUID bit "just in case". Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit db1a9fdd554cb1d8a7099af7925318fc06c6875b Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Nov 10 14:39:03 2020 +0100 x86/CPUID: don't use UB shift when library is built as 32-bit At least the insn emulator test harness will continue to be buildable (and ought to continue to be usable) also as a 32-bit binary. (Right now the CPU policy test harness is, too, but there it may be less relevant to keep it functional, just like e.g. we don't support fuzzing the insn emulator in 32-bit mode.) Hence the library code needs to cope with this. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit b5ad37f8e9284cc147218f7a5193d739ae7b956f Author: Juergen Gross <jgross@xxxxxxxx> Date: Tue Nov 10 14:37:15 2020 +0100 xen/evtchn: revert 52e1fc47abc3a0123 With the event channel lock no longer disabling interrupts commit 52e1fc47abc3a0123 ("evtchn/Flask: pre-allocate node on send path") can be reverted again. Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit 5f2df45ead7c1195142f68b7923047a1e9479d54 Author: Juergen Gross <jgross@xxxxxxxx> Date: Tue Nov 10 14:36:15 2020 +0100 xen/evtchn: rework per event channel lock Currently the lock for a single event channel needs to be taken with interrupts off, which causes deadlocks in some cases. Rework the per event channel lock to be non-blocking for the case of sending an event and removing the need for disabling interrupts for taking the lock. The lock is needed for avoiding races between event channel state changes (creation, closing, binding) against normal operations (set pending, [un]masking, priority changes). Use a rwlock, but with some restrictions: - Changing the state of an event channel (creation, closing, binding) needs to use write_lock(), with ASSERT()ing that the lock is taken as writer only when the state of the event channel is either before or after the locked region appropriate (either free or unbound). - Sending an event needs to use read_trylock() mostly, in case of not obtaining the lock the operation is omitted. This is needed as sending an event can happen with interrupts off (at least in some cases). - Dumping the event channel state for debug purposes is using read_trylock(), too, in order to avoid blocking in case the lock is taken as writer for a long time. - All other cases can use read_lock(). Fixes: e045199c7c9c54 ("evtchn: address races with evtchn_reset()") Signed-off-by: Juergen Gross <jgross@xxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Julien Grall <jgrall@xxxxxxxxxx> (qemu changes not included)
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |