flight 164353 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164353/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 163750
test-amd64-am
On 23.08.2021 19:16, Julien Grall wrote:
> Hi Jan,
>
> On 20/08/2021 10:26, Jan Beulich wrote:
>> On 20.08.2021 11:08, Julien Grall wrote:
>>> On 20/08/2021 08:44, Costin Lupu wrote:
On 8/20/21 9:52 AM, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/include/public/page.h
>> @@ -
On 24.08.2021 07:37, Elliott Mitchell wrote:
> On Mon, Aug 23, 2021 at 09:12:52AM +0200, Jan Beulich wrote:
>> On 21.08.2021 18:25, Elliott Mitchell wrote:
>>> ACPI C-state support might not see too much use, but it does see some.
>>>
>>> With Xen 4.11 and Linux kernel 4.19, I found higher C-states
On 23.08.2021 19:02, Costin Lupu wrote:
> These changes introduce the page related definitions needed for mapping and
> accessing guests memory. These values are intended to be used by any toolstack
> component that needs to map guests memory. Until now, the values were defined
> by the xenctrl.h h
On Mon, Aug 23, 2021 at 09:12:52AM +0200, Jan Beulich wrote:
> On 21.08.2021 18:25, Elliott Mitchell wrote:
> > ACPI C-state support might not see too much use, but it does see some.
> >
> > With Xen 4.11 and Linux kernel 4.19, I found higher C-states only got
> > enabled for physical cores for wh
flight 164374 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164374/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月24日 1:54
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 09/40] xen/x86: Move numa_add_cpu_node to
> common
>
> Hi Wei,
>
flight 164334 xen-4.12-testing real [real]
flight 164417 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164334/
http://logs.test-lab.xenproject.org/osstest/logs/164417/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月23日 18:59
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 22/40] xen/arm: introduce a helper to parse
> device tree processor node
>
>
>
>
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月24日 1:47
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 08/40] xen/x86: Move NUMA memory node map
> functions to common
>
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
Not only x86 ACPI need this macro. Device tree based NUMA
also needs this macro to present max memory block number.
AFAICT, a memory range described in DT cannot be split across multiple
nodes. So I think we want to define NR_NODE_MEMBLKS as NR_MEM_B
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
This function will be reused by Arm later, so we move it
from arch/x86 to common. But we keep cpu_to_node and
node_to_cpumask to x86 header file. Because cpu_to_node and
node_to_cpumask have different implementation for x86 and Arm.
We will move them
Thanks for the review, Jason!
On Tue, Aug 17, 2021 at 9:15 PM Jason Andryuk wrote:
>> The implementation mirrors that of the 'seclabel' and 'init_seclabel'
>> options for user domains. When all used in concert, this enables the
>
> Drop all -> "When used in concert"?
Ack for v3.
>> - changed al
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
In the later patches we will add NUMA support to Arm. Arm
NUMA support will follow current memory node map management
as x86. So this part of code can be common, in this case,
we move this part of code from arch/x86 to common.
I would add "No functi
flight 164324 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164324/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164152
test-armhf-armhf-libvirt 16 sav
These changes refine the changes in 0dbb4be7 which added a dependency to
xenctrl library. We use the XEN_PAGE_* definitions instead of the XC_PAGE_*
definitions and therefore we get rid of the unnecessary dependency.
Signed-off-by: Costin Lupu
---
tools/libs/foreignmemory/Makefile | 2 ++
tool
Hi Jan,
On 20/08/2021 10:26, Jan Beulich wrote:
On 20.08.2021 11:08, Julien Grall wrote:
On 20/08/2021 08:44, Costin Lupu wrote:
On 8/20/21 9:52 AM, Jan Beulich wrote:
--- /dev/null
+++ b/xen/include/public/page.h
@@ -0,0 +1,36 @@
+/
These changes refine the changes in d1b32abd which added a dependency to
xenctrl library. We use the XEN_PAGE_* definitions instead of the XC_PAGE_*
definitions and therefore we get rid of the unnecessary dependency.
Signed-off-by: Costin Lupu
---
tools/libs/gnttab/Makefile | 2 ++
tools/libs/
These changes introduce the page related definitions needed for mapping and
accessing guests memory. These values are intended to be used by any toolstack
component that needs to map guests memory. Until now, the values were defined
by the xenctrl.h header, therefore whenever a component had to use
We use the values provided by the Xen public interface for defining the
XC_PAGE_* macros.
Signed-off-by: Costin Lupu
---
tools/include/xenctrl.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index b77726eab7..52a1768ee
This series tries to fix a side-effect introduced by commits 0dbb4be7 and
d1b32abd which added a dependency to xenctrl for foreignmemory and gnntab
libraries library only because they needed to use the XC_PAGE_* values.
These changes introduce the XEN_PAGE_* definitions that will be used by any
to
Hi Julien,
[Keep only arm maintainers in the CC list]
> On 23 Aug 2021, at 13:10, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 23/08/2021 11:32, Bertrand Marquis wrote:
>> On arm architecture we might have heterogeneous platforms with different
>> types of cores. As a guest can potentialy run o
flight 164316 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Hi,
> On 23 Aug 2021, at 14:22, Julien Grall wrote:
>
>
>
> On 23/08/2021 13:39, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 23 Aug 2021, at 12:47, Julien Grall wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On 23/08/2021 11:32, Bertrand Marquis wrote:
Replace the code in p2
On 23/08/2021 13:39, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 23 Aug 2021, at 12:47, Julien Grall wrote:
Hi Bertrand,
On 23/08/2021 11:32, Bertrand Marquis wrote:
Replace the code in p2m trying to find a sane value for the VMID size
supported and the PAR to use. We are now
Hi Julien,
> On 23 Aug 2021, at 12:47, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 23/08/2021 11:32, Bertrand Marquis wrote:
>> Replace the code in p2m trying to find a sane value for the VMID size
>> supported and the PAR to use. We are now using the boot cpuinfo as the
>> values there are san
On Mon, Aug 23, 2021 at 12:07:44PM +0200, Jan Beulich wrote:
> On 23.08.2021 11:33, Anthony PERARD wrote:
> > On Mon, Aug 23, 2021 at 09:07:32AM +0200, Jan Beulich wrote:
> >> On 23.08.2021 02:40, osstest service owner wrote:
> >>> commit d06eb2d1d9dd8da1ed84bd08c5783a0264fe2b64
> >>> Author: L
On 23/08/2021 12:47, Julien Grall wrote:
Hi Bertrand,
On 23/08/2021 11:32, Bertrand Marquis wrote:
Replace the code in p2m trying to find a sane value for the VMID size
supported and the PAR to use. We are now using the boot cpuinfo as the
values there are sanitized during boot and the value
Hi Bertrand,
On 23/08/2021 11:32, Bertrand Marquis wrote:
On arm architecture we might have heterogeneous platforms with different
types of cores. As a guest can potentialy run on any of those cores we
have to present them cpu features which are compatible with all cores
and discard the features
Hi Bertrand,
On 23/08/2021 11:32, Bertrand Marquis wrote:
Replace the code in p2m trying to find a sane value for the VMID size
supported and the PAR to use. We are now using the boot cpuinfo as the
values there are sanitized during boot and the value for those
parameters is now the safest possi
On 23/08/2021 09:47, Wei Chen wrote:
Hi Julien,
Hi Wei,
-Original Message-
From: Julien Grall
Sent: 2021年8月20日 2:11
To: Wei Chen ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org; jbeul...@suse.com
Cc: Bertrand Marquis
Subject: Re: [XEN RFC PATCH 22/40] xen/arm: introduce
Define a sanitize_cpu function to be called on secondary cores to
sanitize the system cpuinfo structure.
The safest value is taken when possible and the system is marked tainted
if we encounter values which are incompatible with each other.
Call the update_system_features function on all secondar
Sanitize CTR_EL0 value between cores.
In most cases different values will taint Xen but if different
i-cache policies are found, we choose the one which will be compatible
between all cores in terms of invalidation/data cache flushing strategy.
In this case we need to activate the TID2 bit in HCR
Use arm64 cpu feature sanitization to TAIN Xen if different DCZID values
are found (ftr_dczid is using only STRICT method).
In this case actual memory being cleaned by DC ZVA operations would be
different depending on the cores which could make a guest zeroing too
much or too little memory if it is
As we will sanitize the content of boot_cpu_data it will not really
contain the boot cpu information but the system sanitize information.
Rename the structure to system_cpuinfo so the user is informed that this
is the system wide available feature and not anymore the features of the
boot cpu.
The o
Replace the code in p2m trying to find a sane value for the VMID size
supported and the PAR to use. We are now using the boot cpuinfo as the
values there are sanitized during boot and the value for those
parameters is now the safest possible value on the system.
On arm32, the system will panic if
Import structures declared in Linux file arch/arm64/kernel/cpufeature.c
and the required types from arch/arm64/include/asm/cpufeature.h.
Current code has been imported from Linux 5.13-rc5 (Commit ID
cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9) and copied into cpufeature.c
in arm64 code and cpufeature
Import some ID registers definitions from Linux sysreg header to have
required shift definitions for all ID registers fields.
Those are required to reuse the cpufeature sanitization system from
Linux kernel.
Signed-off-by: Bertrand Marquis
---
Changes in v2: Rebase
---
xen/include/asm-arm/arm64
On arm architecture we might have heterogeneous platforms with different
types of cores. As a guest can potentialy run on any of those cores we
have to present them cpu features which are compatible with all cores
and discard the features which are only available on some cores.
As the features can
On 23.08.2021 11:33, Anthony PERARD wrote:
> On Mon, Aug 23, 2021 at 09:07:32AM +0200, Jan Beulich wrote:
>> On 23.08.2021 02:40, osstest service owner wrote:
>>> commit d06eb2d1d9dd8da1ed84bd08c5783a0264fe2b64
>>> Author: Laszlo Ersek
>>> Date: Wed May 26 22:14:24 2021 +0200
>>>
>>>
branch xen-4.14-testing
xenbranch xen-4.14-testing
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu g
On Mon, Aug 23, 2021 at 03:25:00PM +0900, AKASHI Takahiro wrote:
> Hi Stefan,
>
> On Tue, Aug 17, 2021 at 11:41:01AM +0100, Stefan Hajnoczi wrote:
> > On Wed, Aug 04, 2021 at 12:20:01PM -0700, Stefano Stabellini wrote:
> > > > Could we consider the kernel internally converting IOREQ messages from
Am Thu, 19 Aug 2021 17:23:26 +0100
schrieb Ian Jackson :
> Anthony PERARD writes ("Re: preparations for 4.15.1 and 4.13.4"):
> > Also, Olaf want them to be backported to 4.14, see
> > <20210629095952.7b0b94c1.o...@aepfle.de>
> I'm unsure about this. The diff seems moderately large. Also, a
On Mon, Aug 23, 2021 at 09:07:32AM +0200, Jan Beulich wrote:
> On 23.08.2021 02:40, osstest service owner wrote:
> > commit d06eb2d1d9dd8da1ed84bd08c5783a0264fe2b64
> > Author: Laszlo Ersek
> > Date: Wed May 26 22:14:24 2021 +0200
> >
> > OvmfPkg/PlatformPei: remove Xen support
>
flight 164312 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164312/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164131
test-amd64-i386-xl-qemut-win7-amd64 19
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月20日 2:11
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 22/40] xen/arm: introduce a helper to parse
> device tree process
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月20日 2:10
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 22/40] xen/arm: introduce a helper to parse
> device tree process
Am Thu, 19 Aug 2021 17:46:28 +0100
schrieb Ian Jackson :
> I would be happy to take fixes like these for stable branches. I
> tried a git cherry-pick but it didn't apply. Would you like to supply
> backports ?
This script worked for me in staging-4.13:
set -ex
git cherry-pick -ex e54c433adf01a
On 23.08.21 04:13, CGEL wrote:
From: Jing Yangyang
Use BUG_ON instead of a if condition followed by BUG.
Generated by: scripts/coccinelle/misc/bugon.cocci
Reported-by: Zeal Robot
Signed-off-by: Jing Yangyang
---
arch/x86/xen/time.c | 20
1 file changed, 8 insertions(
flight 164309 xen-unstable real [real]
flight 164403 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164309/
http://logs.test-lab.xenproject.org/osstest/logs/164403/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 21.08.2021 18:25, Elliott Mitchell wrote:
> ACPI C-state support might not see too much use, but it does see some.
>
> With Xen 4.11 and Linux kernel 4.19, I found higher C-states only got
> enabled for physical cores for which Domain 0 had a corresponding vCPU.
> On a machine where Domain 0 ha
On 23.08.2021 02:40, osstest service owner wrote:
> branch xen-4.12-testing
> xenbranch xen-4.12-testing
> job test-amd64-i386-xl-qemuu-ovmf-amd64
> testid debian-hvm-install
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.gi
52 matches
Mail list logo
