|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 107217: regressions - FAIL
flight 107217 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107217/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 5 xen-install fail REGR. vs. 107160 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 107160 test-armhf-armhf-libvirt 13 saverestore-support-check fail like 107160 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 107160 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107160 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 107160 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107160 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 107160 test-amd64-amd64-xl-rtds 9 debian-install fail like 107160 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass build-arm64-pvops 5 kernel-build fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass version targeted for testing: xen 045d5d10ee5f0066a7e71d1fe18f9c7c27d64703 baseline version: xen 4d0240e03349fd0715332eae65372e0a47b5a43b Last test of basis 107160 2017-04-03 16:15:19 Z 2 days Failing since 107173 2017-04-04 04:22:28 Z 2 days 3 attempts Testing same since 107217 2017-04-05 13:52:44 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Bhavesh Davda <bhavesh.davda@xxxxxxxxxx> Iurii Konovalenko <iurii.konovalenko@xxxxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <julien.grall@xxxxxxx> Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx> Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> Oleksandr Grytsov <oleksandr_grytsov@xxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> Seraphime Kirkovski <kirkseraph@xxxxxxxxx> Shanker Donthineni <shankerd@xxxxxxxxxxxxxx> Stefano Stabellini <sstabellini@xxxxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops fail build-armhf-pvops pass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvh-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumprun-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumprun-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvh-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-arm64-arm64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-arm64-arm64-libvirt-qcow2 blocked test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-arm64-arm64-xl-rtds blocked test-armhf-armhf-xl-rtds pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-amd64-xl-qemut-winxpsp3 pass test-amd64-i386-xl-qemut-winxpsp3 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3 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 045d5d10ee5f0066a7e71d1fe18f9c7c27d64703 Author: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx> Date: Mon Mar 20 09:03:27 2017 +0200 xen/sndif: Add sound-device ABI Add ABI for the two halves of a para-virtualized sound driver to communicate with each other. The ABI allows implementing audio playback and capture as well as volume control and possibility to mute/unmute audio sources. Note: depending on the use-case backend can expose more sound cards and PCM devices/streams than the underlying HW physically has by employing SW mixers, configuring virtual sound streams, channels etc. Thus, allowing fine tunned configurations per frontend. Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx> Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@xxxxxxxx> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@xxxxxxxxxxxxxxx> commit c4bdbec00c9063736361124a3492ebceabfaed06 Author: Seraphime Kirkovski <kirkseraph@xxxxxxxxx> Date: Tue Apr 4 14:40:48 2017 +0200 libxc: fix segfault on uninitialized xch->fmem Currently in xc_interface_open, xch->fmem is not initialized and in some rare case the code fails before ever assigning a value to it. I got this in master: $ sudo ./xl/xl run xencall: error: Could not obtain handle on privileged command interface: No such file or directory Segmentation fault This initializes the whole xch_buff to 0. Signed-off-by: Seraphime Kirkovski <kirkseraph@xxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 938fd2586eb081bcbd694f4c1f09ae6a263b0d90 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Apr 4 14:47:46 2017 +0200 memory: properly check guest memory ranges in XENMEM_exchange handling The use of guest_handle_okay() here (as introduced by the XSA-29 fix) is insufficient here, guest_handle_subrange_okay() needs to be used instead. Note that the uses are okay in - XENMEM_add_to_physmap_batch handling due to the size field being only 16 bits wide, - livepatch_list() due to the limit of 1024 enforced on the number-of-entries input (leaving aside the fact that this can be called by a privileged domain only anyway), - compat mode handling due to counts there being limited to 32 bits, - everywhere else due to guest arrays being accessed sequentially from index zero. This is CVE-2017-7228 / XSA-212. Reported-by: Jann Horn <jannh@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit cde048340afa125514f77368f62fbea9805a68f9 Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Apr 4 12:46:47 2017 +0200 x86/vioapic: allow the vIO APIC to have a variable number of pins Although it's still always set to VIOAPIC_NUM_PINS (48). Add a new field to the hvm_ioapic struct to contain the number of pins (number of IO redirection table entries) and turn the redirection table into a variable sized array. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 6cbc358a1416025d057fd1866b8e37d907cc0662 Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Apr 4 12:46:14 2017 +0200 x86/hvm: convert gsi_assert_count into a variable size array Rearrange the fields of hvm_irq so that gsi_assert_count can be converted into a variable size array and add a new field to account the number of GSIs. Due to this changes the irq member in the hvm_domain struct also needs to become a pointer set at runtime. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit fa645b31536995c5a8ff7943fa6222deaceba49a Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Apr 4 12:39:42 2017 +0200 x86/irq: rename NR_HVM_IRQS and break it's dependency on VIOAPIC_NUM_PINS Rename it to NR_HVM_DOMU_IRQS, and get it's value from the size of the DomU vIO APIC redirection table. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 5c5216e825332c83b1965b5a39a6100f9dde34da Author: Bhavesh Davda <bhavesh.davda@xxxxxxxxxx> Date: Tue Apr 4 11:34:57 2017 +0200 kexec: clear kexec_image slot when unloading kexec image When kexec_do_unload calls kexec_swap_images to get the old kexec_image to free, it passes NULL for the new kexec_image pointer. The new slot wasn't being cleared in such a case, leading to a stale pointer being left behind in the kexec_image array and Xen panics in subsequent load/unload operations. Signed-off-by: Bhavesh Davda <bhavesh.davda@xxxxxxxxxx> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Reviewed-by: Daniel Kiper <daniel.kiper@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit bc32c6e3f34f46aada3a9ee80fff171e1ce75d69 Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Apr 4 11:34:26 2017 +0200 x86/ioapic: add prototype for io_apic_gsi_base to io_apic.h So that the function can be called from other files without adding prototypes to each of them. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit 2d227eeb1caf82075db513a9b265c8eb6d06c57d Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Apr 4 11:33:06 2017 +0200 x86/hvm: introduce hvm_domain_irq macro Introduce a macro to get a pointer to the hvm_irq for a HVM domain. No functional change. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> [VT-d] Acked-by: Jan Beulich <jbeulich@xxxxxxxx> commit a891a308e9b1e71153a929ed55baa990243a7bdb Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Apr 4 11:32:04 2017 +0200 x86/vioapic: expand hvm_vioapic to contain vIO APIC internal state This is required in order to have a variable number of vIO APIC pins, instead of the current fixed value (48). Note that this patch only expands the fields of the hvm_vioapic struct, without actually introducing any new fields or functionality. The reason to expand the hvm_vioapic structure instead of the hvm_hw_vioapic one is that the variable number of pins functionality is only going to be used by the hardware domain, so no modifications are needed to the save format. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit b32d442abd92cdd4d8f2a2e7794cfee9dba7fe22 Author: Stefano Stabellini <sstabellini@xxxxxxxxxx> Date: Fri Mar 31 15:37:07 2017 -0700 setup vwfi correctly on cpu0 parse_vwfi runs after init_traps on cpu0, potentially resulting in the wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so in their case init_traps will write the correct set of flags to HCR_EL2. For cpu0, fix the issue by changing HCR_EL2 setting from a new presmp_initcall. Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Reviewed-by: Julien Grall <julien.grall@xxxxxxx> commit 80f9c316708400cea4417e36337267d3b26591db Author: Julien Grall <julien.grall@xxxxxxx> Date: Mon Apr 3 11:53:23 2017 +0100 xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain When booting using ACPI, not all MMIOs can be discovered by parsing the static tables or the UEFI memory map. A lot of them will be described in the DSDT. However, Xen does not have an AML parser which requires us to find a different approach. During the first discussions on supporting ACPI (see design doc [1]), it was decided to rely on the hardware domain to make a request to the hypervisor to map the MMIO region in stage-2 page table before accessing it. This approach works fine if the OS has limited hooks to modify the page tables. In the case of Linux kernel, notifiers have been added to map the MMIO regions when adding a new AMBA/platform device. Whilst this is covering most of the MMIOs, some of them (e.g OpRegion, ECAM...) are not related to a specific device or the driver is not using the AMBA/platform API. So more hooks would need to be added in the code. Various approaches have been discussed (see [2]), one of them was to create stage-2 mappings seamlessly in Xen upon hardware memory faults. This approach was first ruled out because it relies on the hardware domain to probe the region before any use. So this would not work when DMA'ing to another device's MMIO region when the device is protected by an SMMU. It has been pointed out that this is a limited use case compare to DMA'ing between MMIO and RAM. This patch implements this approach. All MMIOs region will be mapped in stage-2 using p2m_mmio_direct_c (i.e normal memory outer and inner write-back cacheable). The stage-1 page table will be in control of the memory attribute. This is fine because the hardware domain is a trusted domain. Note that MMIO will only be mapped on a data abort fault. It is assumed that it will not be possible to execute code from MMIO (p2m_mmio_direct_c will forbid that). As mentioned above, this solution will cover most of the cases. If a platform requires to do DMA'ing to another device's MMIO region without any access performed by the OS. Then it will be expected to have specific platform code in the hypervisor to map the MMIO at boot time or the OS to use the existing hypercalls (i.e XENMEM_add_to_add_physmap{,_batch}) before any access. [1] https://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html [2] https://marc.info/?l=linux-arm-kernel&m=148469169210500&w=2 Signed-off-by: Julien Grall <julien.grall@xxxxxxx> Tested-by: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx> Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |