flight 177343 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177343/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 090642db7ac124c336da72e1954e1fb09e816fb0
baseline version:
ovmf
flight 177300 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177300/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 176804
flight 177328 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177328/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1b5420e8071b4f9ba13136f19365542dfe66bf04
baseline version:
ovmf
flight 177298 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177298/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 177222
test-amd64-amd64-xl-qemuu-win7-amd64
On Tue, 14 Feb 2023, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Copy the build output of Yocto builds to binaries/ and export binaries/
> among the jobs artifacts so that they can be reused by other jobs.
>
> Signed-off-by: Stefano Stabellini
> ---
>
From: Stefano Stabellini
As part of the arm32 dom0 test, also create a simple domU using xl. To
do that, we need the toolstack installed in the dom0 rootfs. We switch
to using the kernel and rootfs built by the Yocto arm32 job.
Remove the PCI node from the host device tree: it is unused but
From: Stefano Stabellini
Copy the build output of Yocto builds to binaries/ and export binaries/
among the jobs artifacts so that they can be reused by other jobs.
Signed-off-by: Stefano Stabellini
---
automation/build/yocto/build-yocto.sh | 6 ++
automation/gitlab-ci/build.yaml | 1
From: Stefano Stabellini
We are going to use artifacts produced by the Yocto builds in test jobs.
Signed-off-by: Stefano Stabellini
---
automation/gitlab-ci/build.yaml | 51 +
automation/gitlab-ci/test.yaml | 45 -
2 files changed,
Hi all,
This patch series add a domU creation test based on xl for arm32. To do
that, it reuses the existing arm32 dom0 test, and also reuses the Yocto
qemuarm build output.
Pipeline (with reduced amount of jobs):
https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/80349
On 2/14/23 6:53 PM, Boris Ostrovsky wrote:
On 2/14/23 11:13 AM, Jan Beulich wrote:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -32,6 +34,7 @@
#include
#include
On 2/14/23 11:13 AM, Jan Beulich wrote:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -32,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
Hello Stefano,
Stefano Stabellini writes:
> On Wed, 31 Aug 2022, Volodymyr Babchuk wrote:
>> domain->pdevs_lock protects access to domain->pdev_list.
>> As this, it should be used when we are adding, removing on enumerating
>> PCI devices assigned to a domain.
>>
>> This enables more
On Tue, 14 Feb 2023, Michal Orzel wrote:
> Add a debian container with cppcheck installation routine inside,
> capable of performing cppcheck analysis on Xen-only build including
> cross-builds for arm32 and x86_64.
>
> Populate build jobs making use of that container to run cppcheck
> analysis
On Tue, 14 Feb 2023, Michal Orzel wrote:
> Add a new test job qemu-smoke-dom0less-arm32-gcc-without-dom0 in debug
> and non-debug variant that will execute qemu-smoke-dom0less-arm32.sh
> script to test dom0less domU boot without dom0 (i.e. true dom0less
> configuration).
>
> By passing
On Tue, 14 Feb 2023, Michal Orzel wrote:
> Xen supports booting gzip compressed kernels, therefore add a new test
> job qemu-smoke-dom0less-arm32-gcc-gzip in debug and non-debug variant
> that will execute qemu-smoke-dom0less-arm32.sh script to test booting
> a domU with a gzip compressed kernel
On Tue, 14 Feb 2023, Michal Orzel wrote:
> Add a new test job qemu-smoke-dom0less-arm32-gcc-staticmem in debug
> and non-debug variant that will execute qemu-smoke-dom0less-arm32.sh
> script to test static memory allocation feature. The test case itself
> is directly taken from dom0less arm64
On Tue, 14 Feb 2023, Michal Orzel wrote:
> At the moment, we only perform a single arm32 test in our CI, checking
> whether dom0 boots successfully or not. This is mostly because we do not
> have any arm32 runners and we only execute a hypervisor only build.
>
> In order not to leave the arm32
On Tue, 14 Feb 2023, Michal Orzel wrote:
> Due to the limited x86 CI resources slowing down the whole pipeline,
> switch the arm32 cross builds to be executed on arm64 which is much more
> capable. For that, rename the existing debian container dockerfile
> from unstable-arm32-gcc to
On Tue, 14 Feb 2023, Jan Beulich wrote:
> On 14.02.2023 09:56, Luca Fancellu wrote:
> > --- a/docs/misra/exclude-list.json
> > +++ b/docs/misra/exclude-list.json
> > @@ -1,4 +1,209 @@
> > {
> > "version": "1.0",
> > -"content": []
> > +"content": [
> > +{
> > +
flight 177305 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177305/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi,
Qubes recently incorporated my HWP patches, but there was a report of
a laptop, Thinkpad X1 Carbon Gen 4 with a Skylake processor, locking
up during boot when HWP is enabled. A user found a kernel bug that
seems to be the same issue:
https://bugzilla.kernel.org/show_bug.cgi?id=110941.
That
flight 177271 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177271/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 177229
test-amd64-i386-xl-qemuu-win7-amd64
On 2/14/23 2:48 AM, Jan Beulich wrote:
On 13.02.2023 21:53, Boris Ostrovsky wrote:
On 2/13/23 11:41 AM, Jan Beulich wrote:
On 13.02.2023 17:30, Xenia Ragiadakou wrote:
On 2/13/23 17:11, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/cpu/Makefile
+++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-27672 / XSA-426
x86: Cross-Thread Return Address Predictions
ISSUE DESCRIPTION
=
It has been discovered that on some AMD CPUs, the RAS (Return Address
Stack, also called RAP
On Tue, 14 Feb 2023, Andrew Cooper wrote:
> On 14/02/2023 3:39 pm, Michal Orzel wrote:
> > diff --git a/automation/build/debian/unstable-cppcheck.dockerfile
> > b/automation/build/debian/unstable-cppcheck.dockerfile
> > new file mode 100644
> > index ..54b99f87dfec
> > --- /dev/null
>
On 14/02/2023 3:39 pm, Michal Orzel wrote:
> diff --git a/automation/build/debian/unstable-cppcheck.dockerfile
> b/automation/build/debian/unstable-cppcheck.dockerfile
> new file mode 100644
> index ..54b99f87dfec
> --- /dev/null
> +++
Hi,
On 1/27/23 4:37 PM, Srivatsa S. Bhat wrote:
> From: "Srivatsa S. Bhat (VMware)"
>
> The comment that says mwait_play_dead() returns only on failure is a
> bit misleading because mwait_play_dead() could actually return for
> valid reasons (such as mwait not being supported by the platform)
On 2/14/23 18:24, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
The functions svm_load_segs() and svm_load_segs_prefetch() are AMD-V specific
so guard their calls in common code with AMD_SVM.
Since AMD_SVM depends on HVM, it can be used alone.
No functional change
On 2/14/23 18:46, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
VIO_realmode_completion is specific to vmx realmode, so guard the completion
handling code with INTEL_VMX.
While it means slightly bigger a code change, personally I'd prefer if
VIO_realmode_completion simply
On 14.02.2023 17:22, Oleksii wrote:
> On Mon, 2023-02-13 at 13:24 +0100, Jan Beulich wrote:
>> On 03.02.2023 18:05, Oleksii Kurochko wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -92,6 +92,12 @@ config STATIC_MEMORY
>>>
>>> If unsure, say N.
>>>
>>> +config
On 2/14/23 18:36, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
To be able to use cpu_has_svm/vmx_* macros in common code without enclosing
Both in the title and here the spelling you use made me first think that
you talk about "cpu_has_svm". May I suggest you follow what
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
> VIO_realmode_completion is specific to vmx realmode, so guard the completion
> handling code with INTEL_VMX.
While it means slightly bigger a code change, personally I'd prefer if
VIO_realmode_completion simply didn't exist as enumerator when !VMX.
On Mon, 2023-02-13 at 14:13 +0100, Jan Beulich wrote:
> On 03.02.2023 18:05, Oleksii Kurochko wrote:
> > Since the generic version of bug.h stuff was introduced it
> > is necessary to rename all uses of to
> >
> > Signed-off-by: Oleksii Kurochko
>
> Doesn't this change need to come ahead of
On Mon, 2023-02-13 at 14:10 +0100, Jan Beulich wrote:
> On 03.02.2023 18:05, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
>
> Is there anything keeping x86 from also using the generic
> do_bug_frame()?
> If not, switching over would then likely mean no need for the new
> Kconfig
>
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
> To be able to use cpu_has_svm/vmx_* macros in common code without enclosing
Both in the title and here the spelling you use made me first think that
you talk about "cpu_has_svm". May I suggest you follow what we typically
do and use
On Mon, 2023-02-13 at 14:02 +0100, Jan Beulich wrote:
> On 03.02.2023 18:05, Oleksii Kurochko wrote:
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -18,6 +18,7 @@ config ARM
> > select HAS_PDX
> > select HAS_PMAP
> > select IOMMU_FORCE_PT_SHARE
> > +
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
> The symbol svm_stgi_label is AMD-V specific so guard its usage in common code
> with AMD_SVM.
>
> Since AMD_SVM depends on HVM, it can be used alone.
> Also, use #ifdef instead of #if.
>
> No functional change intended.
>
> Signed-off-by: Xenia
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
> The functions svm_load_segs() and svm_load_segs_prefetch() are AMD-V specific
> so guard their calls in common code with AMD_SVM.
>
> Since AMD_SVM depends on HVM, it can be used alone.
>
> No functional change intended.
>
> Signed-off-by: Xenia
Hi Jan!
Thanks a lot for starting the review of the patch series!
On Mon, 2023-02-13 at 13:24 +0100, Jan Beulich wrote:
> On 03.02.2023 18:05, Oleksii Kurochko wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -92,6 +92,12 @@ config STATIC_MEMORY
> >
> > If
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
> The functions vmx_vmcs_enter() and vmx_vmcs_exit() are VT-x specific.
> Guard their calls with INTEL_VMX.
>
> No functional change intended.
>
> Signed-off-by: Xenia Ragiadakou
With whatever the final name of the Kconfig control is going to be
If this VM assist is available (to PV guests only), use it to
- avoid issuing an IBPB ourselves upon entry from user mode (which the
hypervisor would then have to emulate, as the MSR write traps),
- suppress the IBPB in the hypervisor if we don't mean to have one
issued.
As there's no good
Since both kernel and user mode run in ring 3, they run in the same
"predictor mode". While the kernel could take care of this itself, doing
so would be yet another item distinguishing PV from native. Additionally
we're in a much better position to issue the barrier command, and we can
save a #GP
When the outgoing vCPU had IBPB issued and RSB overwritten upon entering
Xen, then there's no need for a 2nd barrier during context switch.
Note that SCF_entry_ibpb is always clear for the idle domain, so no
explicit idle domain check is needed to augment the feature check
(which is simply
In order to avoid clobbering Xen's own predictions, defer the barrier as
much as possible. Merely mark the CPU as needing a barrier issued the
next time we're exiting to guest context.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
I couldn't find any sensible (central/unique) place
In order to be able to defer the context switch IBPB to the last
possible point, add logic to the exit-to-guest paths to issue the
barrier there, including the "IBPB doesn't flush the RSB/RAS"
workaround. Since alternatives, for now at least, can't nest, emit JMP
to skip past both constructs where
Versions of the two final patches were submitted standalone earlier
on. The series here tries to carry out a suggestion from Andrew,
which the two of us have been discussing. Then said previously posted
patches are re-based on top, utilizing the new functionality.
Xen:
1: spec-ctrl: add logic to
Add a debian container with cppcheck installation routine inside,
capable of performing cppcheck analysis on Xen-only build including
cross-builds for arm32 and x86_64.
Populate build jobs making use of that container to run cppcheck
analysis to produce a text report (xen-cppcheck.txt) containing
This patch series aims at improving the arm32 CI testing by introducing
the dom0less-based tests. It creates a foundation for further test expansion.
This is particularly important now, when OSSTEST arm32 stuff is down and we
need to have at least some coverage in gitlab CI.
Note:
First patch is
Due to the limited x86 CI resources slowing down the whole pipeline,
switch the arm32 cross builds to be executed on arm64 which is much more
capable. For that, rename the existing debian container dockerfile
from unstable-arm32-gcc to unstable-arm64v8-arm32-gcc and use
arm64v8/debian:unstable as
At the moment, we only perform a single arm32 test in our CI, checking
whether dom0 boots successfully or not. This is mostly because we do not
have any arm32 runners and we only execute a hypervisor only build.
In order not to leave the arm32 testing in such a poor state, add a
script
Add a new test job qemu-smoke-dom0less-arm32-gcc-staticmem in debug
and non-debug variant that will execute qemu-smoke-dom0less-arm32.sh
script to test static memory allocation feature. The test case itself
is directly taken from dom0less arm64 testing.
Populate build jobs to compile Xen with
Add a new test job qemu-smoke-dom0less-arm32-gcc-without-dom0 in debug
and non-debug variant that will execute qemu-smoke-dom0less-arm32.sh
script to test dom0less domU boot without dom0 (i.e. true dom0less
configuration).
By passing "without-dom0" as a test variant, the test will clear the
dom0
Xen supports booting gzip compressed kernels, therefore add a new test
job qemu-smoke-dom0less-arm32-gcc-gzip in debug and non-debug variant
that will execute qemu-smoke-dom0less-arm32.sh script to test booting
a domU with a gzip compressed kernel image (in our case zImage).
By passing "gzip" as
On Tue, Feb 14, 2023 at 12:47:00PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> The following commits are also in the tip tree as different commits
> (but the same patches):
>
> 415dab3c1796 ("drivers/xen/hypervisor: Expose Xen SIF flags to userspace")
> 336f560a8917 ("x86/xen: don't let
On Tue, Feb 14, 2023 at 08:51:09AM +0100, Juergen Gross wrote:
> On 13.02.23 22:01, Demi Marie Obenour wrote:
> > On Mon, Feb 13, 2023 at 10:26:11AM +0100, Juergen Gross wrote:
> > > On 07.02.23 03:10, Demi Marie Obenour wrote:
> > > > When a grant entry is still in use by the remote domain, Linux
flight 177242 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177242/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 15
On 14/02/2023 11:45 am, Michal Orzel wrote:
> Hi Andrew,
>
> On 14/02/2023 12:00, Andrew Cooper wrote:
>>
>> On 13/02/2023 2:23 pm, Michal Orzel wrote:
>>> Add a debian container with cppcheck installation routine inside,
>>> capable of performing cppcheck analysis on Xen-only build including
>>>
Hi Andrew,
On 14/02/2023 12:00, Andrew Cooper wrote:
>
>
> On 13/02/2023 2:23 pm, Michal Orzel wrote:
>> Add a debian container with cppcheck installation routine inside,
>> capable of performing cppcheck analysis on Xen-only build including
>> cross-builds for arm32 and arm64.
>>
>> Populate
> From: Xen-devel on behalf of Mihails
> Strasuns
> Sent: Thursday, January 19, 2023 10:13 AM
> To: xen-devel@lists.xenproject.org
> Cc: mstra...@amazon.com ; Raphael Ning
> ; Bjoern Doebel ; Martin Pohlack
>
> Subject: [PATCH v1 3/4] livepatch-gcc: Ignore buildid.o
>
> From: Raphael
> From: Xen-devel on behalf of Mihails
> Strasuns
> Sent: Thursday, January 19, 2023 10:13 AM
> To: xen-devel@lists.xenproject.org
> Cc: mstra...@amazon.com ; Raphael Ning
> ; Bjoern Doebel ; Martin Pohlack
>
> Subject: [PATCH v1 2/4] livepatch-build: Allow a patch to introduce new
>
flight 177229 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177229/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 177171
On 13/02/2023 2:23 pm, Michal Orzel wrote:
> Add a debian container with cppcheck installation routine inside,
> capable of performing cppcheck analysis on Xen-only build including
> cross-builds for arm32 and arm64.
>
> Populate build jobs making use of that container to run cppcheck
> analysis
> On 14 Feb 2023, at 09:51, Jan Beulich wrote:
>
> On 14.02.2023 09:56, Luca Fancellu wrote:
>> Add a way to exclude files from the scan, in this way we can skip
>> some findings from the report on those files that Xen doesn't own.
>>
>> To do that, introduce the exclude-list.json file under
> -Original Message-
> From: Stewart Hildebrand
> Sent: Wednesday, February 8, 2023 4:55 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Julien Grall ; Bertrand Marquis
> ; Volodymyr Babchuk
>
> Subject: Re: [PATCH v1 01/13] xen/arm:
On 14.02.2023 09:56, Luca Fancellu wrote:
> --- a/docs/misra/exclude-list.json
> +++ b/docs/misra/exclude-list.json
> @@ -1,4 +1,209 @@
> {
> "version": "1.0",
> -"content": []
> +"content": [
> +{
> +"rel_path": "arch/arm/arm64/cpufeature.c"
> +},
> +
On 14.02.2023 09:56, Luca Fancellu wrote:
> Add a way to exclude files from the scan, in this way we can skip
> some findings from the report on those files that Xen doesn't own.
>
> To do that, introduce the exclude-list.json file under docs/misra,
> this file will be populated with relative
This serie is introducing an exclusion list for the misra analysis, at the
moment only cppcheck can benefit from it because it's the tool where we
control every step and configuration.
Exclude a file from the analysis is the last step we should do, but sometime it
is unavoidable because we can't
Add a way to exclude files from the scan, in this way we can skip
some findings from the report on those files that Xen doesn't own.
To do that, introduce the exclude-list.json file under docs/misra,
this file will be populated with relative path to the files/folder
to be excluded.
Introduce a
Add entries to the exclude-list.json for those files that need to be
excluded from the analysis scan.
Signed-off-by: Luca Fancellu
Signed-off-by: Michal Orzel
---
This list is originated from Michal's work here:
flight 177239 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177239/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 540522fec06b87bf11ad5624abe23b515f282d60
baseline version:
ovmf
70 matches
Mail list logo
