|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 148397: regressions - FAIL
flight 148397 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/148397/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 16 guest-start/debian.repeat fail REGR. vs. 148323 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen e19d3a942e4b6f6c5b19287a4a6f5020bdab2936 baseline version: xen 99f1c935190986068a36fb5e78a00e6b71b08f25 Last test of basis 148323 2020-03-09 15:01:29 Z 1 days Failing since 148381 2020-03-10 15:05:53 Z 0 days 3 attempts Testing same since 148393 2020-03-10 19:01:05 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Jan Beulich <jbeulich@xxxxxxxx> Paul Durrant <paul@xxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> Tamas K Lengyel <tamas@xxxxxxxxxxxxx> Tim Deegan <tim@xxxxxxx> 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 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass 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 e19d3a942e4b6f6c5b19287a4a6f5020bdab2936 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Mar 10 17:06:57 2020 +0100 memaccess: reduce include dependencies The common header doesn't itself need to include public/vm_event.h nor public/memory.h. Drop their inclusion. This requires using the non- typedef names in two prototypes and an inline function; by not changing the callers and function definitions at the same time it'll remain certain that the build would fail if the typedef itself was changed. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx> commit 15b6242230ba1cf92c774ad2b14f4f25411aa644 Author: Paul Durrant <paul@xxxxxxx> Date: Tue Mar 10 17:06:09 2020 +0100 x86 / p2m: replace page_list check in p2m_alloc_table... ... with a check of domain_tot_pages(). The check of page_list prevents the prior allocation of PGC_extra pages, whereas what the code is trying to verify is that the toolstack has not already RAM for the domain. Signed-off-by: Paul Durrant <paul@xxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 0198960edbf0e681cef59fd81c994643e7b148e0 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Mar 10 15:38:25 2020 +0100 vmevent: reduce include dependencies There's no need for virtually everything to include public/vm_event.h. Move its inclusion out of sched.h. This requires using the non-typedef name in p2m_mem_paging_resume()'s prototype; by not changing the function definition at the same time it'll remain certain that the build would fail if the typedef itself was changed. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> Reviewed-by: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> Acked-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx> commit 0604e1549ac522443f01d49774f73cfa67561358 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Mar 10 15:37:30 2020 +0100 IOMMU: iommu_snoop is x86-only In fact it's VT-d specific, but we don't have a way yet to build code for just one vendor. Provide a #define for the opposite case. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Reviewed-by: Paul Durrant <paul@xxxxxxx> commit 0de9500d1c2c3f37b3cd86b180dc1d2aafa2ad1b Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Mar 10 15:36:45 2020 +0100 IOMMU: iommu_qinval is x86-only In fact it's VT-d specific, but we don't have a way yet to build code for just one vendor. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Reviewed-by: Paul Durrant <paul@xxxxxxx> commit cd550c3963ea521205e80df935c17d4cdee02844 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Mar 10 15:35:57 2020 +0100 IOMMU: iommu_igfx is x86-only In fact it's VT-d specific, but we don't have a way yet to build code for just one vendor. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Reviewed-by: Paul Durrant <paul@xxxxxxx> commit 4ccbb9c337de30f4b5fd9caf87c673200cb19de9 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Mar 10 15:33:56 2020 +0100 IOMMU: iommu_intpost is x86/HVM-only Provide a #define for all other cases. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Reviewed-by: Paul Durrant <paul@xxxxxxx> commit 5f62fdcb4c7c63205abfe5a5cbf77025cb9fd431 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Mar 10 15:32:16 2020 +0100 IOMMU: iommu_intremap is x86-only Provide a #define for other cases; it didn't seem worthwhile to me to introduce an IOMMU_INTREMAP Kconfig option at this point. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Reviewed-by: Paul Durrant <paul@xxxxxxx> commit c9495bd7dff587ce770b2318037d6a1d0511bd72 Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Mar 10 15:30:27 2020 +0100 x86/hap: improve hypervisor assisted guest TLB flush The current implementation of the hypervisor assisted flush for HAP is extremely inefficient. First of all there's no need to call paging_update_cr3, as the only relevant part of that function when doing a flush is the ASID vCPU flush, so just call that function directly. Since hvm_asid_flush_vcpu is protected against concurrent callers by using atomic operations there's no need anymore to pause the affected vCPUs. Finally the global TLB flush performed by flush_tlb_mask is also not necessary, since we only want to flush the guest TLB state it's enough to trigger a vmexit on the pCPUs currently holding any vCPU state, as such vmexit will already perform an ASID/VPID update, and thus clear the guest TLB. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Wei Liu <wl@xxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 920d5f31883c9c4c4e8092a693572fe01b6f7270 Author: Roger Pau Monné <roger.pau@xxxxxxxxxx> Date: Tue Mar 10 15:29:24 2020 +0100 x86/paging: add TLB flush hook Add shadow and hap implementation specific helpers to perform guest TLB flushes. Note that the code for both is exactly the same at the moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by further patches that will add implementation specific optimizations to them. No functional change intended. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Wei Liu <wl@xxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> Reviewed-by: Paul Durrant <pdurrant@xxxxxxxx> [viridian] Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit 261ef8ccbd28526d69c3a6c5944709f81624741a Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Mar 10 15:27:56 2020 +0100 x86: refine APIC ID restriction Now that we distinguish "restricted" and "full" interrupt remapping mode, the 8-bit-APIC-ID restriction also needs to be enforced for "restricted". Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> commit 1ba66a870eba43d52d3e5e7af1a055bf5b16b30d Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Tue Mar 10 15:25:58 2020 +0100 AMD/IOMMU: without XT, x2APIC needs to be forced into physical mode The wider cluster mode APIC IDs aren't generally representable. Convert the iommu_intremap variable into a tristate, allowing the AMD IOMMU driver to signal this special restriction to the apic_x2apic_probe(). (Note: assignments to the variable get adjusted, while existing consumers - all assuming a boolean property - are left alone.) While we are not aware of any hardware/firmware with this as a restriction, it is a situation which could be created on fully x2apic- capable systems via firmware settings. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |