flight 173522 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173522/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 172547
branch xen-4.15-testing
xenbranch xen-4.15-testing
job build-arm64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and
flight 173506 xen-unstable-smoke real [real]
flight 173523 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173506/
http://logs.test-lab.xenproject.org/osstest/logs/173523/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 173497 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 173447
Hi all,
> -Original Message-
> Subject: [xen-4.15-testing test] 173498: regressions - FAIL
>
> flight 173498 xen-4.15-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/173498/
>
> Regressions :-(
I think these regressions are from the backporting happened
flight 173495 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173495/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 172549
build-arm64
flight 173498 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173498/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 172547
flight 173496 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173496/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 20 guest-localmigrate/x10 fail REGR. vs. 172550
flight 173493 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173493/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-raw 12 debian-di-installfail REGR. vs. 172623
On Tue, 11 Oct 2022, Leo Yan wrote:
> > > The second question is how to mitigate the long latency when send data
> > > from DomU. A possible solution is the Xen network forend driver copies
> > > skb into mediate (bounce) buffer, just like what does in Xen net
> > > backend driver with
flight 173501 xen-unstable-smoke real [real]
flight 173503 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173501/
http://logs.test-lab.xenproject.org/osstest/logs/173503/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 173491 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173491/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462
On Tue, Oct 11, 2022 at 11:59:01AM +0200, Jan Beulich wrote:
> On 11.10.2022 05:42, Demi Marie Obenour wrote:
> > A previous patch tried to get Linux to use the ESRT under Xen if it is
> > in memory of type EfiRuntimeServicesData. However, this turns out to be
> > a bad idea. Ard Biesheuvel
flight 173492 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173492/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 14 guest-start fail REGR. vs. 173457
flight 173494 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 172547
On Thu, Aug 18, 2022 at 03:03:33PM +0200, Jan Beulich wrote:
> From: Artem Bityutskiy
>
> On Sapphire Rapids Xeon (SPR) the C1 and C1E states are basically mutually
> exclusive - only one of them can be enabled. By default, 'intel_idle' driver
> enables C1 and disables C1E. However, some users
The current logic for AMD SSBD context switches it on every
vm{entry,exit} if the Xen and guest selections don't match. This is
expensive when not using SPEC_CTRL, and hence should be avoided as
much as possible.
When SSBD is not being set from SPEC_CTRL on AMD don't context switch
at
Hardware that exposes SSB_NO can implement the setting of SSBD as a
no-op because it's not affected by SSB.
Take advantage of that and allow exposing VIRT_SPEC_CTRL.SSBD to guest
running on hadrware that has SSB_NO. Only set VIRT_SSBD on the max
policy though, as the feature is only intended to
Hello,
The following series aims to remove running C code with GIF=0 on the AMD
vm{entry,exit} paths. As a result, the context switching of SSBD is
done when context switching vCPUs, and hence Xen code is run with the
guest selection of SSBD.
First patch is the one strictly needed, but patches
Like on Intel AMD guests are now capable of setting SSBD on their own,
either from SPEC_CTRL or from VIRT_SPEC_CTRL. As a result the
unconditional setting of SSBD from Xen in order to cope with the bit
not being exposed to guests is no longer needed.
Remove the Xen command line `spec-ctrl=ssbd`
Since the VIRT_SPEC_CTRL.SSBD selection is no longer context switched
on vm{entry,exit} there's no need to use a synthetic feature bit for
it anymore.
Remove the bit and instead use a global variable.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/amd.c
Hi,
Are any further changes needed to upstream this patch series?
Cheers,
-jenny
-Original Message-
From: Jennifer Herbert
Sent: 15 September 2022 21:40
To: jbeul...@suse.com; Andrew Cooper ; w...@xen.org;
Roger Pau Monne
Cc: xen-devel@lists.xenproject.org; Jennifer Herbert
On 11.10.2022 15:33, Julien Grall wrote:
> Hi Jan,
>
> On 11/10/2022 14:28, Jan Beulich wrote:
>> On 11.10.2022 15:01, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 11/10/2022 12:59, Jan Beulich wrote:
On 16.07.2022 16:56, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
Hi Jan,
On 11/10/2022 14:28, Jan Beulich wrote:
On 11.10.2022 15:01, Julien Grall wrote:
Hi Jan,
On 11/10/2022 12:59, Jan Beulich wrote:
On 16.07.2022 16:56, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Rework Arm implementation to store grant table frame GFN
in struct page_info
On 11.10.2022 15:01, Julien Grall wrote:
> Hi Jan,
>
> On 11/10/2022 12:59, Jan Beulich wrote:
>> On 16.07.2022 16:56, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>>>
>>> Rework Arm implementation to store grant table frame GFN
>>> in struct page_info directly instead of keeping
All,
the release is due around the end of the month. Since 4.15's general
support period has ended earlier this month, this is going to be the
final XenProject-coordinated release from this branch.
Please point out backports you find missing from the respective staging
branch, but which you
Hi Jan,
On 11/10/2022 12:59, Jan Beulich wrote:
On 16.07.2022 16:56, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Rework Arm implementation to store grant table frame GFN
in struct page_info directly instead of keeping it in
standalone status/shared arrays. This patch is based on
Hi Stefano,
> On 8 Oct 2022, at 00:36, Stefano Stabellini wrote:
>
> On Wed, 24 Aug 2022, Bertrand Marquis wrote:
>> This patch series is a first attempt to check if we could use Yocto in
>> gitlab ci to build and run xen on qemu for arm, arm64 and x86.
>>
>> The first patch is making sure
Hi Andrew,
> -Original Message-
> From: Andrew Cooper
> > (If it will not cause too much time of digging, would you mind adding a
> > "Fixes:" tag pointing to the original commit that missing this
> > ` vcpu_has_nscb()` check when you do the committing? I think this would
> > help to
On Fri, Oct 7, 2022 at 9:12 PM Henry Wang wrote:
>
> Hi Andrew and Jason,
>
> > -Original Message-
> > From: Andrew Cooper
> > Subject: Re: [PATCH] argo: Remove reachable ASSERT_UNREACHABLE
> >
> > On 07/10/2022 20:31, Jason Andryuk wrote:
> > > I observed this ASSERT_UNREACHABLE in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-33749 / XSA-413
version 2
XAPI open file limit DoS
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-33748 / XSA-411
version 3
lock order inversion in transitive grant copy handling
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
Hi Stefano,
On Mon, Oct 10, 2022 at 04:50:46PM -0700, Stefano Stabellini wrote:
> +Xen/Linux maintainers
Thanks for reviewing.
[...]
> > Throughput result:
> >
> > Profile netperf (Mbits/sec)ddsperf (Mbits/sec)
> > Xen-Dom0939.41 > 620
> > Xen-DomU
On 16.07.2022 16:56, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Rework Arm implementation to store grant table frame GFN
> in struct page_info directly instead of keeping it in
> standalone status/shared arrays. This patch is based on
> the assumption that a grant table page is
Hi!
> From: Kees Cook
>
> [ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
>
> Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
> and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
> offset. Work around this by using a direct assignment of
acpi_numa is a specific NUMA switch for ACPI NUMA implementation.
Other NUMA implementation may not need this switch. But this switch is
not only used by ACPI code, it is also used directly in some general
NUMA logic code. So far this hasn't caused any problem because Xen only
has x86 implementing
flight 173489 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173489/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 173462
On Tue, Sep 20, 2022 at 04:30:41PM +0200, Jan Beulich wrote:
> On 20.09.2022 12:22, Marek Marczykowski-Górecki wrote:
> > On Mon, Aug 22, 2022 at 12:00:27PM +0200, Marek Marczykowski-Górecki wrote:
> >> On Mon, Aug 22, 2022 at 11:53:50AM +0200, Jan Beulich wrote:
> >>> On 21.08.2022 18:14, Marek
x86 has implemented a set of codes to process NUMA nodes. These
codes will parse NUMA memory and processor information from
ACPI SRAT table. But except some ACPI specific codes, most
of the process code like memory blocks validation, node memory
range updates and some sanity check can be reused by
Currently the maximum number of NUMA nodes is a hardcoded value.
This provides little flexibility unless changing the code.
Introduce a new Kconfig option to change the maximum number of
NUMA nodes conveniently. Also considering that not all
architectures support NUMA, this Kconfig option is only
There are some codes in x86/numa.c can be shared by common
architectures to implememnt NUMA support. Just like some
variables and functions to check and store NUMA memory map.
And some variables and functions to do NUMA initialization.
In this patch, we move them to common/numa.c and xen/numa.h
The sanity check of nodes_cover_memory is also a requirement of
other architectures that support NUMA. But now, the code of
nodes_cover_memory is tied to the x86 E820. In this case, we
introduce arch_get_ram_range to decouple architecture specific
memory map from this function. This means, other
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" undeclared (first use in this function).
This is because in the common header file,
(The Arm device tree based NUMA support patch set contains 35
patches. In order to make stuff easier for reviewers, I split
them into 3 parts:
1. Preparation. I have re-sorted the patch series. And moved
independent patches to the head of the series - merged in [1]
2. Move generically usable
On 11/10/2022 11:44, Henry Wang wrote:
> Hi Jan,
>
>> -Original Message-
>> From: Jan Beulich
>> Subject: [4.17?] Re: [PATCH] x86emul: respect NSCB
>>
>> On 10.10.2022 18:44, Andrew Cooper wrote:
>>> On 15/09/2022 08:22, Jan Beulich wrote:
protmode_load_seg() would better adhere to
Hi Stefano,
On 11/10/2022 01:26, Stefano Stabellini wrote:
On Sun, 9 Oct 2022, Julien Grall wrote:
When creating new components, new files, or importing code please follow
the conventions outlined below. As a general rule, whenever code using a
license other than GPLv2 is introduced,
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH 2/2][4.17] x86emul: pull permission check ahead for REP
> INS/OUTS
>
> On 10.10.2022 20:08, Andrew Cooper wrote:
> > On 06/10/2022 14:11, Jan Beulich wrote:
> >> Based on observations on a fair range of hardware from
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: [4.17?] Re: [PATCH] x86emul: respect NSCB
>
> On 10.10.2022 18:44, Andrew Cooper wrote:
> > On 15/09/2022 08:22, Jan Beulich wrote:
> >> protmode_load_seg() would better adhere to that "feature" of clearing
> >> base (and
On 10.10.2022 20:56, Andrew Cooper wrote:
> On 06/10/2022 14:11, Jan Beulich wrote:
>> In an entirely different context I came across Linux commit 428e3d08574b
>> ("KVM: x86: Fix zero iterations REP-string"), which points out that
>> we're still doing things wrong: For one, there's no
flight 173490 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173490/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 173468
test-armhf-armhf-libvirt-qcow2 15
On 10.10.2022 20:08, Andrew Cooper wrote:
> On 06/10/2022 14:11, Jan Beulich wrote:
>> Based on observations on a fair range of hardware from both primary
>> vendors even zero-iteration-count instances of these insns perform the
>> port related permission checking first.
>>
>> Fixes: fe300600464c
On 10.10.2022 18:44, Andrew Cooper wrote:
> On 15/09/2022 08:22, Jan Beulich wrote:
>> protmode_load_seg() would better adhere to that "feature" of clearing
>> base (and limit) during NULL selector loads.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Andrew Cooper
Thanks.
Henry - this was
On 11.10.2022 05:42, Demi Marie Obenour wrote:
> A previous patch tried to get Linux to use the ESRT under Xen if it is
> in memory of type EfiRuntimeServicesData. However, this turns out to be
> a bad idea. Ard Biesheuvel pointed out that EfiRuntimeServices* memory
> winds up fragmenting both
efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
higher priority than the type of the range. To avoid accessing memory at
runtime which was re-used for other purposes, make
efi_arch_process_memory_map() follow suit. While in theory the same would
apply to
find_ring_mfn() already holds a page reference when trying to obtain a
writable type reference. We shouldn't make assumptions on the general
reference count limit being effectively "infinity". Obtain merely a type
ref, re-using the general ref by only dropping the previously acquired
one in the
Not passing P2M_UNSHARE to get_page_from_gfn() means there won't even be
an attempt to unshare the referenced page, without any indication to the
caller (e.g. -EAGAIN). Note that guests have no direct control over
which of their pages are shared (or paged out), and hence they have no
way to make
flight 173488 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173488/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-seattle 13 debian-fixup fail in 173482 pass in 173488
test-arm64-arm64-libvirt-raw 17
Hi,
> On 11 Oct 2022, at 00:58, Stefano Stabellini wrote:
>
> On Mon, 10 Oct 2022, Jan Beulich wrote:
>> On 08.10.2022 21:08, Julien Grall wrote:
>>> On 06/10/2022 15:11, Jan Beulich wrote:
> ... the space cannot become ordinary RAM, then such a precaution
> wouldn't be necessary. After
58 matches
Mail list logo
