|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 141866: regressions - FAIL
flight 141866 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141866/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 141821 test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141821 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass version targeted for testing: xen 433387661ec789962dffd8ec929f59fdee78194c baseline version: xen ff22a91b4c45f9310d0ec0d7ee070d84a373dd87 Last test of basis 141821 2019-09-25 14:00:59 Z 0 days Testing same since 141827 2019-09-25 18:00:48 Z 0 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Christian Lindig <christian.lindig@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <julien.grall@xxxxxxx> Paul Durrant <paul.durrant@xxxxxxxxxx> Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx> Wei Liu <wl@xxxxxxx> jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail 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 433387661ec789962dffd8ec929f59fdee78194c Author: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx> Date: Tue Sep 24 15:46:48 2019 +0000 xen/arm: optee: update description in Kconfig OP-TEE mediator now is "Tech Preview" state, and we want to update it's description in Kconfig accordingly. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxx> commit e9ad55d9add9c1ddf9cf49418003fb1481129791 Author: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx> Date: Tue Sep 24 15:46:47 2019 +0000 SUPPORT.md: Describe OP-TEE mediator With the latest patches to the mediator, it can be considered as Technological Preview feature. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxx> commit c2c141f0f4248963cedcb972534423cf9092ae52 Author: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx> Date: Tue Sep 24 15:46:45 2019 +0000 xen/arm: optee: handle shared buffer translation error There is a case possible, when OP-TEE asks guest to allocate shared buffer, but Xen for some reason can't translate buffer's addresses. In this situation we should do two things: 1. Tell guest to free allocated buffer, so there will be no memory leak for guest. 2. Tell OP-TEE that buffer allocation failed. To ask guest to free allocated buffer we should perform the same thing, as OP-TEE does - issue RPC request. This is done by filling request buffer (luckily we can reuse the same buffer, that OP-TEE used to issue original request) and then return to guest with special return code. Then we need to handle next call from guest in a special way: as RPC was issued by Xen, not by OP-TEE, it should be handled by Xen. Basically, this is the mechanism to preempt OP-TEE mediator. The same mechanism can be used in the future to preempt mediator during translation large (>512 pages) shared buffers. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxx> commit babde47a3feda6dd4ba318e1e57bd2ee9f2c1116 Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Wed Sep 25 16:14:55 2019 +0200 introduce a 'passthrough' configuration option to xl.cfg... ...and hence the ability to disable IOMMU mappings, and control EPT sharing. This patch introduces a new 'libxl_passthrough' enumeration into libxl_domain_create_info. The value will be set by xl either when it parses a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough hardware specified for the domain. If the value of the passthrough configuration option is 'disabled' then the XEN_DOMCTL_CDF_iommu flag will be clear in the xen_domctl_createdomain flags, thus allowing the toolstack to control whether the domain gets IOMMU mappings or not (where previously they were globally set). If the value of the passthrough configuration option is 'sync_pt' then a new 'iommu_opts' field in xen_domctl_createdomain will be set with the value XEN_DOMCTL_IOMMU_no_sharept. This will override the global default set in iommu_hap_pt_share, thus allowing the toolstack to control whether EPT sharing is used for the domain. If the value of passthrough is 'enabled' then xl will choose an appropriate default according to the type of domain and hardware support. NOTE: The 'iommu_memkb' overhead in libxl_domain_build_info will now only be set if passthrough is 'sync_pt' (or xl has chosen this mode as a default). Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxx> Reviewed-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> commit 8d8db5a4ad267bca663bc1e41dccb53e072d73d2 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Wed Sep 25 16:14:21 2019 +0200 tools/ocaml: abi check: Cope with consecutive relevant enums If the end of one enum is the `type' line for the next enum, we would not notice it. Fix this by reordering the code, and getting rid of the else: now if the "we are within an enum" branch decides that it's the end of the enum, it unsets $ei and we then immediately process the line as a "not within an enum" line - ie as the start of the next one. Reported-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Acked-by: Christian Lindig <christian.lindig@xxxxxxxxxx> commit 80ff3d338dc93260b41ffeeebb0f852c2edef9ce Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Wed Sep 25 16:12:49 2019 +0200 iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros Thes macros really ought to live in the common xen/iommu.h header rather then being distributed amongst architecture specific iommu headers and xen/sched.h. This patch moves them there. NOTE: Disabling 'sharept' in the command line iommu options should really be hard error on ARM (as opposed to just being ignored), so define 'iommu_hap_pt_share' to be true for ARM (via ARM-selected CONFIG_IOMMU_FORCE_PT_SHARE). Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxx> commit f89f555827a6634582ff78ef26e7167b2bddbbfa Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Wed Sep 25 16:12:02 2019 +0200 remove late (on-demand) construction of IOMMU page tables Now that there is a per-domain IOMMU-enable flag, which should be set if any device is going to be passed through, stop deferring page table construction until the assignment is done. Also don't tear down the tables again when the last device is de-assigned; defer that task until domain destruction. This allows the has_iommu_pt() helper and iommu_status enumeration to be removed. Calls to has_iommu_pt() are simply replaced by calls to is_iommu_enabled(). Remaining open-coded tests of iommu_hap_pt_share can also be replaced by calls to iommu_use_hap_pt(). The arch_iommu_populate_page_table() and iommu_construct() functions become redundant, as does the 'strict mode' dom0 page_list mapping code in iommu_hwdom_init(), and iommu_teardown() can be made static is its only remaining caller, iommu_domain_destroy(), is within the same source module. All in all, about 220 lines of code are removed from the hypervisor (at the expense of some additions in the toolstack). NOTE: This patch will cause a small amount of extra resource to be used to accommodate IOMMU page tables that may never be used, since the per-domain IOMMU-enable flag is currently set to the value of the global iommu_enable flag. A subsequent patch will add an option to the toolstack to allow it to be turned off if there is no intention to assign passthrough hardware to the domain. To account for the extra resource, 'iommu_memkb' has been added to domain_build_info. This patch sets it to a value calculated based on the domain's maximum memory when the P2M sharing is either not supported or globally disabled, or zero otherwise. However, when the toolstack option mentioned above is added, it will also be zero if the per-domain IOMMU-enable flag is turned off. Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Reviewed-by: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> Acked-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Julien Grall <julien.grall@xxxxxxx> Acked-by: Wei Liu <wl@xxxxxxx> commit 322609f9c9809ddc106362c24683c939524510d8 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Sep 25 16:03:48 2019 +0200 AMD/IOMMU: tidy struct ivrs_mappings Move the device flags field up into an unused hole, thus shrinking overall structure size by 8 bytes. Use bool and uint<N>_t as appropriate. Drop pointless (redundant) initializations. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 34a9ef62d3d29ddafbec6b3409074dd67eba7109 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Sep 25 16:02:59 2019 +0200 AMD/IOMMU: restrict interrupt remapping table sizes There's no point setting up tables with more space than a PCI device can use. For both MSI and MSI-X we can determine how many interrupts could be set up at most. Tables allocated during ACPI table parsing, however, will (for now at least) continue to be set up to have maximum size. Note that until we would want to use sub-page allocations here there's no point checking whether both MSI and MSI-X are supported by a device - an order-0 allocation will fit the dual case in any event, no matter that the MSI-X vector count may be smaller than the MSI one. On my Rome system this reduces space needed from just over 1k pages to about 125. Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit bb038f311687554483fb997cfee213760029aeaf Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Sep 25 16:02:21 2019 +0200 AMD/IOMMU: replace INTREMAP_ENTRIES Prepare for the number of entries to not be the maximum possible, by separating checks against maximum size from ones against actual size. For caller side simplicity have alloc_intremap_entry() return the maximum possible value upon allocation failure, rather than the first just out-of-bounds one. Have the involved functions already take all the subsequently needed arguments here already, to reduce code churn in the patch actually making the allocation size dynamic. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx> commit 93a78101260b22510c5f823577ff826fbfc46136 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Sep 25 16:01:31 2019 +0200 x86/PCI: read maximum MSI vector count early Rather than doing this every time we set up interrupts for a device anew (and then in several places) fill this invariant field right after allocating struct pci_dev. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> commit 4e5e40fbd5852b2b638e5d9cf775d52f93b3fecb Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Sep 25 16:00:46 2019 +0200 AMD/IOMMU: make phantom functions share interrupt remapping tables Rather than duplicating entries in amd_iommu_msi_msg_update_ire(), share the tables. This mainly requires some care while freeing them, to avoid freeing memory blocks twice. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx> commit d7cfeb7c13ed60be949714cd4befa7edb3211c9b Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Sep 25 16:00:05 2019 +0200 AMD/IOMMU: don't blindly allocate interrupt remapping tables ACPI tables are free to list far more device coordinates than there are actual devices. By delaying the table allocations for most cases, and doing them only when an actual device is known to be present at a given position, overall memory used for the tables goes down from over 500k pages to just over 1k (on my system having such ACPI table contents). Tables continue to get allocated right away for special entries (IO-APIC, HPET) as well as for alias IDs. While in the former case that's simply because there may not be any device at a given position, in the latter case this is to avoid having to introduce ref-counting of table usage. The change involves invoking iterate_ivrs_mappings(amd_iommu_setup_device_table) a second time, because the function now wants to be able to find PCI devices, which isn't possible yet when IOMMU setup happens very early during x2APIC mode setup. In this context amd_iommu_init_interrupt() gets renamed as well. The logic adjusting a DTE's interrupt remapping attributes also gets changed, such that the lack of an IRT would result in target aborted rather than non-remapped interrupts (should any occur). Note that for now phantom functions get separate IRTs allocated, as was the case before. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> (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 |