|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen-unstable-smoke test] 186416: regressions - FAIL
flight 186416 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/186416/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-build fail REGR. vs. 186411 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a 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 version targeted for testing: xen 43d5c5d5f70b3f5419e7ef30399d23adf6ddfa8e baseline version: xen efa6e9f15ba943d154e8d7b29384581915b2aacd Last test of basis 186411 2024-06-19 12:00:22 Z 0 days Testing same since 186412 2024-06-19 15:03:58 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Julien Grall <jgrall@xxxxxxxxxx> Stefano Stabellini <sstabellini@xxxxxxxxxx> jobs: build-arm64-xsm pass build-amd64 pass build-armhf fail build-amd64-libvirt pass test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm pass 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 43d5c5d5f70b3f5419e7ef30399d23adf6ddfa8e Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Wed Jun 19 14:11:07 2024 +0200 xen: avoid UB in guest handle arithmetic At least XENMEM_memory_exchange can have huge values passed in the nr_extents and nr_exchanged fields. Adding such values to pointers can overflow, resulting in UB. Cast respective pointers to "unsigned long" while at the same time making the necessary multiplication explicit. Remaining arithmetic is, despite there possibly being mathematical overflow, okay as per the C99 spec: "A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type." The overflow that we need to guard against is checked for in array_access_ok(). Note that in / down from array_access_ok() the address value is only ever cast to "unsigned long" anyway, which is why in the invocation from guest_handle_subrange_okay() the value doesn't need casting back to pointer type. In compat grant table code change two guest_handle_add_offset() to avoid passing in negative offsets. Since {,__}clear_guest_offset() need touching anyway, also deal with another (latent) issue there: They were losing the handle type, i.e. the size of the individual objects accessed. Luckily the few users we presently have all pass char or uint8 handles. Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> commit 267122a24c499d26278ab2dbdfb46ebcaaf38474 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Apr 30 16:14:36 2021 +0100 x86/defns: Clean up X86_{XCR0,XSS}_* constants With the exception of one case in read_bndcfgu() which can use ilog2(), the *_POS defines are unused. Drop them. X86_XCR0_X87 is the name used by both the SDM and APM, rather than X86_XCR0_FP. No functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> commit 71cacfb035f4a78ee10970dc38a3baa04d387451 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Apr 30 20:17:55 2021 +0100 x86/cpuid: Fix handling of XSAVE dynamic leaves First, if XSAVE is available in hardware but not visible to the guest, the dynamic leaves shouldn't be filled in. Second, the comment concerning XSS state is wrong. VT-x doesn't manage host/guest state automatically, but there is provision for "host only" bits to be set, so the implications are still accurate. Introduce xstate_compressed_size() to mirror the uncompressed one. Cross check it at boot. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> commit fdb7e77fea4cb1c98dc51dd891a47f7e94612ad4 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Apr 30 20:17:55 2021 +0100 x86/cpu-policy: Simplify recalculate_xstate() Make use of xstate_uncompressed_size() helper rather than maintaining the running calculation while accumulating feature components. The rest of the CPUID data can come direct from the raw cpu policy. All per-component data form an ABI through the behaviour of the X{SAVE,RSTOR}* instructions. Use for_each_set_bit() rather than opencoding a slightly awkward version of it. Mask the attributes in ecx down based on the visible features. This isn't actually necessary for any components or attributes defined at the time of writing (up to AMX), but is added out of an abundance of caution. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> commit df09dfb94de66f7523837c050616a382aa2c7d17 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Apr 30 20:17:55 2021 +0100 x86/xstate: Rework xstate_ctxt_size() as xstate_uncompressed_size() We're soon going to need a compressed helper of the same form. The size of the uncompressed image depends on the single element with the largest offset + size. Sadly this isn't always the element with the largest index. Name the per-xstate-component cpu_policy struture, for legibility of the logic in xstate_uncompressed_size(). Cross-check with hardware during boot, and remove hw_uncompressed_size(). This means that the migration paths don't need to mess with XCR0 just to sanity check the buffer size. It also means we can drop the "fastpath" check against xfeature_mask (there to skip some XCR0 writes); this path is going to be dead logic the moment Xen starts using supervisor states itself. The users of hw_uncompressed_size() in xstate_init() can (and indeed need) to be replaced with CPUID instructions. They run with feature_mask in XCR0, and prior to setup_xstate_features() on the BSP. No practical change. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> commit a09022a09e1a79b3f9574993993bfad803b32596 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu May 23 00:55:34 2024 +0100 x86/boot: Collect the Raw CPU Policy earlier on boot This is a tangle, but it's a small step in the right direction. In the following change, xstate_init() is going to start using the Raw policy. calculate_raw_cpu_policy() is sufficiently separate from the other policies to safely move like this. No functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> commit d31a111940de5431c8bf465b1d38b89f1130a24b Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Feb 21 17:56:57 2020 +0000 x86/xstate: Cross-check dynamic XSTATE sizes at boot Right now, xstate_ctxt_size() performs a cross-check of size with CPUID in for every call. This is expensive, being used for domain create/migrate, as well as to service certain guest CPUID instructions. Instead, arrange to check the sizes once at boot. See the code comments for details. Right now, it just checks hardware against the algorithm expectations. Later patches will cross-check Xen's XSTATE calculations too. Introduce more X86_XCR0_* and X86_XSS_* constants CPUID bits. This is to maximise coverage in the sanity check, even if we don't expect to use/virtualise some of these features any time soon. Leave HDC and HWP alone for now; we don't have CPUID bits from them stored nicely. Only perform the cross-checks when SELF_TESTS are active. It's only developers or new hardware liable to trip these checks, and Xen at least tracks "maximum value ever seen in xcr0" for the lifetime of the VM, which we don't want to be tickling in the general case. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> commit 9e6dbbe8bf400aacb99009ddffa91d2a0c312b39 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed May 22 17:23:54 2024 +0100 x86/xstate: Fix initialisation of XSS cache The clobbering of this_cpu(xcr0) and this_cpu(xss) to architecturally invalid values is to force the subsequent set_xcr0() and set_msr_xss() to reload the hardware register. While XCR0 is reloaded in xstate_init(), MSR_XSS isn't. This causes get_msr_xss() to return the invalid value, and logic of the form: old = get_msr_xss(); set_msr_xss(new); ... set_msr_xss(old); to try and restore said invalid value. The architecturally invalid value must be purged from the cache, meaning the hardware register must be written at least once. This in turn highlights that the invalid value must only be used in the case that the hardware register is available. Fixes: f7f4a523927f ("x86/xstate: reset cached register values on resume") Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> commit aba98c8d671bd290e978ec154d0baf042e093a65 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Fri Jun 14 13:05:40 2024 +0100 xen/arch: Centralise __read_mostly and __ro_after_init These living in cache.h is inherited from Linux, but cache.h is not a terribly appropriately location for them to live. __read_mostly is an optimisation related to data placement in order to avoid having shared data in cachelines that are likely to be written to, but it really is just a section of the linked image separating data by usage patterns; it has nothing to do with cache sizes or flushing logic. Worse, __ro_after_init was only in xen/cache.h because __read_mostly was in arch/cache.h, and has literally nothing whatsoever to do with caches. Move the definitions into xen/sections.h, which in particular means that RISC-V doesn't need to repeat the problematic pattern. Take the opportunity to provide a short descriptions of what these are used for. For now, leave TODO comments next to the other identical definitions. It turns out that unpicking cache.h is more complicated than it appears because a number of files use it for transitive dependencies. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> commit 82f480944718d9e8340a6ac1af41ece7851115bf Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Jun 18 13:48:35 2024 +0100 xen/irq: Address MISRA Rule 8.3 violation When centralising irq_ack_none(), different architectures had different names for the parameter. As it's type is struct irq_desc *, it should be named desc. Make this consistent. No functional change. Fixes: 8aeda4a241ab ("arch/irq: Make irq_ack_none() mandatory") Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Julien Grall <jgrall@xxxxxxxxxx> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx> (qemu changes not included)
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |