From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xenproject.org
Subject: [xen-unstable-smoke test] 187075: regressions - FAIL
Date: Wed, 31 Jul 2024 16:19:39 +0000 [thread overview]
Message-ID: <osstest-187075-mainreport@xen.org> (raw)
flight 187075 xen-unstable-smoke real [real]
flight 187086 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187075/
http://logs.test-lab.xenproject.org/osstest/logs/187086/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 187068
Tests which did not succeed, but are not blocking:
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 561cba38ff551383a628dc93e64ab0691cfc92bf
baseline version:
xen 6979e17b3f8a18d2ba5dbd4f0623c4061dae0dfc
Last test of basis 187068 2024-07-31 02:02:09 Z 0 days
Testing same since 187075 2024-07-31 11:02:13 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <jgrall@amazon.com>
Roger Pau Monné <roger.pau@citrix.com>
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 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 561cba38ff551383a628dc93e64ab0691cfc92bf
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Wed Jul 31 12:41:22 2024 +0200
x86/altcall: further refine clang workaround
The current code in ALT_CALL_ARG() won't successfully workaround the clang
code-generation issue if the arg parameter has a size that's not a power of 2.
While there are no such sized parameters at the moment, improve the workaround
to also be effective when such sizes are used.
Instead of using a union with a long use an unsigned long that's first
initialized to 0 and afterwards set to the argument value.
Reported-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Suggested-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 1fc3f77113dd43b14fa7ef5936dcdba120c0b63f
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Wed Jul 31 12:41:02 2024 +0200
x86/dom0: fix restoring %cr3 and the mapcache override on PV build error
One of the error paths in the PV dom0 builder section that runs on the guest
page-tables wasn't restoring the Xen value of %cr3, neither removing the
mapcache override.
Fixes: 079ff2d32c3d ('libelf-loader: introduce elf_load_image')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 157c693e9a488fe125ffe7adfb807b783a7d1757
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Jul 31 12:40:19 2024 +0200
x86/HVM: get_pat_flags() is needed only by shadow code
Therefore with SHADOW_PAGING=n this is better compiled out, to avoid
leaving around unreachable/dead code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
commit ce6c6a697edf40763a8512369672a399821b17bf
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Jul 31 12:39:35 2024 +0200
public/x86: don't include common xen.h from arch-specific one
No other arch-*.h does so, and arch-x86/xen.h really just takes the role
of arch-x86_32.h and arch-x86_64.h (by those two forwarding there). With
xen.h itself including the per-arch headers, doing so is also kind of
backwards anyway, and just calling for problems. There's exactly one
place where arch-x86/xen.h is included when really xen.h is meant (for
wanting XEN_GUEST_HANDLE_64() to be made available, the default
definition of which lives in the common xen.h).
This then addresses a violation of Misra C:2012 Directive 4.10
("Precautions shall be taken in order to prevent the contents of a
header file being included more than once").
Reported-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
commit 96f35de69e593a9d9c348ae33ba17cf3cc5a9a79
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Jul 31 12:36:14 2024 +0200
x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt()
There's no use of them anymore except in the definitions of the non-
underscore-prefixed aliases.
On Arm convert the (renamed) inline function to a macro.
On x86 rename the inline functions, adjust the virt_to_maddr() #define,
and purge the maddr_to_virt() one, thus eliminating a bogus cast which
would have allowed the passing of a pointer type variable into
maddr_to_virt() to go silently.
No functional change intended.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Julien Grall <jgrall@amazon.com>
commit a5b8e72e9e2e59941cc76978725bb9ee04eba722
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu Jul 18 21:22:41 2024 +0100
arch/domain: Clean up the idle domain remnants in arch_domain_create()
With arch_domain_create() no longer being called with the idle domain, drop
the last remaining logic.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
commit a259a658f203e3b17734c42f2ca6e75344e2de22
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu Jul 18 21:20:52 2024 +0100
xen/domain: Simpliy domain_create() now the idle domain is complete earlier
With x86 implementing arch_init_idle_domain(), there is no longer any need to
call arch_domain_create() with the idle domain.
Have the idle domain exit early with all other system domains. Move the
static-analysis ASSERT() earlier. Then, remove the !is_idle_domain()
protections around the majority of domain_create() and remove one level of
indentation.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
commit fdb4d76ff3c44752d067fe598c0c021389030c63
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu Jul 18 21:12:31 2024 +0100
x86/domain: Implement arch_init_idle_domain()
The idle domain needs d->arch.ctxt_switch initialised on x86. Implement the
new arch_init_idle_domain() in order to do this.
Intentionally remove cpu_policy's initialisation to ZERO_BLOCK_PTR. It has
never tripped since it's introduction, and is weird to have in isolation
without a similar approach on other pointers.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 694ce812e7cb643236e8e677aca763c5f2aa4f4b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu Jul 18 20:54:05 2024 +0100
xen/domain: Introduce arch_init_idle_domain()
The idle domain causes a large amount of complexity in domain_create() because
of x86's need to initialise d->arch.ctxt_switch in arch_domain_create().
In order to address this, introduce an optional hook to perform extra
initialisation of the idle domain.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
(qemu changes not included)
reply other threads:[~2024-07-31 16:19 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=osstest-187075-mainreport@xen.org \
--to=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.