Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月25日 21:49
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 23/40] xen/arm: introduce a helper to parse
> device tree memory
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月25日 21:39
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Jan Beulich
>
> Subject: Re: [XEN RFC PATCH 19/40] xen: fdt: Introduce a helper to check
> fdt node type
>
> H
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月25日 21:24
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 13/40] xen/arm: introduce numa_set_node for
> Arm
>
>
>
> On 25/08/2021 13:07, W
flight 164457 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164457/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164324
test-armhf-armhf-libvirt 16 sav
Hi Jan, Julien,
> -Original Message-
> From: Jan Beulich
> Sent: 2021年8月25日 21:36
> To: Julien Grall ; Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org
> Subject: Re: [XEN RFC PATCH 14/40] xen/arm: set NUMA nodes max number to
> 64 by default
>
On Wed, Aug 25, 2021 at 05:55:09PM +0200, Jan Beulich wrote:
> On 25.08.2021 17:47, Marek Marczykowski-Górecki wrote:
> > If so, I guess the issue is the kernel trying to write directly, instead
> > of via some hypercall, right?
>
> Indeed. Or to be precise - the kernel isn't supposed to be "writi
On Tue, Aug 24, 2021 at 08:14:41AM +0200, Jan Beulich wrote:
> 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.
flight 164461 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164461/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7b4a99be8a39c12d3a7fc4b8db9f0eab4ac688d5
baseline version:
ovmf 8dd4fc5be6189666b37e5
Thanks for the big contribution!
I just wanted to let you know that the series passed all the gitlab-ci
build tests without issues.
The runtime tests originally failed due to unrelated problems (there was
a Debian testing upgrade that broke Gitlab-CI.) I fix the underlying
issue and restarted the
flight 164454 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164454/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs.
163761
test-amd64-
flight 164470 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164470/
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
flight 164455 xen-4.15-testing real [real]
flight 164494 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164455/
http://logs.test-lab.xenproject.org/osstest/logs/164494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
branch xen-4.13-testing
xenbranch xen-4.13-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
flight 164426 xen-4.14-testing real [real]
flight 164491 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164426/
http://logs.test-lab.xenproject.org/osstest/logs/164491/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On Thu, Aug 05, 2021 at 12:28:32AM +0200, Sergio Miguéns Iglesias wrote:
> The code style for most files was fixed. This means that blank lines
> were added when needed (normally after variable declarations), spaces
> before tabs were removed, some code alignment issues were solved, block
> comment
flight 164421 xen-4.12-testing real [real]
flight 164487 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164421/
http://logs.test-lab.xenproject.org/osstest/logs/164487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
Both memory_nodes_parsed and processor_nodes_parsed are using
for Arm and x86 to record parded NUMA memory and CPU. So we
move them to common.
Looking at the usage, they both call:
numa_set...(..., bitmap)
So rather than exporting the two helpers,
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
These two helpers are architecture APIs that are required by
nodes_cover_memory.
Signed-off-by: Wei Chen
---
xen/arch/arm/numa.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index f
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
Sometimes, CPU logical ID maybe different with physical CPU ID.
Xen is using CPU logial ID for runtime usage, so we should use
CPU logical ID to create map between NUMA node and CPU.
This commit message gives the impression that you are trying to fi
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
When cpu boot up, we have add them to NUMA system. In current
stage, we have not parsed the NUMA data, but we have created
a fake NUMA node. So, in this patch, all CPU will be added
to NUMA node#0. After the NUMA data has been parsed from device
tree,
On 25/08/2021 16:02, Jan Beulich wrote:
> On 24.08.2021 23:11, Andrew Cooper wrote:
>> On 18/08/2021 13:44, Andrew Cooper wrote:
>>> On 18/08/2021 12:30, Marek Marczykowski-Górecki wrote:
set_xcr0() and set_msr_xss() use cached value to avoid setting the
register to the same value over an
flight 164484 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164484/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 25.08.2021 17:47, Marek Marczykowski-Górecki wrote:
> On Wed, Aug 25, 2021 at 05:33:54PM +0200, Jan Beulich wrote:
>> On 25.08.2021 17:24, Marek Marczykowski-Górecki wrote:
>>> On recent kernel I get kernel panic when starting a Xen PV domain with
>>> PCI devices assigned. This happens on 5.10.6
On Wed, Aug 25, 2021 at 05:33:54PM +0200, Jan Beulich wrote:
> On 25.08.2021 17:24, Marek Marczykowski-Górecki wrote:
> > On recent kernel I get kernel panic when starting a Xen PV domain with
> > PCI devices assigned. This happens on 5.10.60 (worked on .54) and
> > 5.4.142 (worked on .136):
> >
On 05.08.2021 16:06, Daniel P. Smith wrote:
> The internal define flag is not used by any XSM module, removing the #ifdef
> leaving the generic event channel labeling as always present.
With this description ...
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -120,15 +120,12
On 25.08.2021 17:24, Marek Marczykowski-Górecki wrote:
> On recent kernel I get kernel panic when starting a Xen PV domain with
> PCI devices assigned. This happens on 5.10.60 (worked on .54) and
> 5.4.142 (worked on .136):
>
> [ 13.683009] pcifront pci-0: claiming resource :00:00.0/0
> [
Hi,
On recent kernel I get kernel panic when starting a Xen PV domain with
PCI devices assigned. This happens on 5.10.60 (worked on .54) and
5.4.142 (worked on .136):
[ 13.683009] pcifront pci-0: claiming resource :00:00.0/0
[ 13.683042] pcifront pci-0: claiming resource :00:00.0/1
[
On 05.08.2021 16:06, Daniel P. Smith wrote:
> On Linux when SELinux is put into permissive mode the descretionary access
> controls are still in place. Whereas for Xen when the enforcing state of flask
> is set to permissive, all operations for all domains would succeed, i.e. it
> does not fall bac
On 05.08.2021 16:06, Daniel P. Smith wrote:
> @@ -747,16 +747,16 @@ extern int xsm_dt_policy_init(void **policy_buffer,
> size_t *policy_size);
> extern bool has_xsm_magic(paddr_t);
> #endif
>
> -extern int register_xsm(struct xsm_operations *ops);
> -
> -extern struct xsm_operations dummy_xsm
On 25/08/2021 15:36, Jan Beulich wrote:
> On 25.08.2021 14:12, Andrew Cooper wrote:
>> On 24/08/2021 14:04, Jan Beulich wrote:
>>> On 19.08.2021 18:26, Andrew Cooper wrote:
In some configurations, it is safe to not overwrite the RSB on entry to
Xen.
Both Intel and AMD have guideline
On Wed, Aug 25, 2021 at 07:29:45PM +0900, AKASHI Takahiro wrote:
> On Mon, Aug 23, 2021 at 10:58:46AM +0100, Stefan Hajnoczi wrote:
> > 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 24.08.2021 23:11, Andrew Cooper wrote:
> On 18/08/2021 13:44, Andrew Cooper wrote:
>> On 18/08/2021 12:30, Marek Marczykowski-Górecki wrote:
>>> set_xcr0() and set_msr_xss() use cached value to avoid setting the
>>> register to the same value over and over. But suspend/resume implicitly
>>> rese
Hi Ian,
On 24/08/2021 14:38, Ian Jackson wrote:
Julien Grall writes ("Re: Xen 4.16: Proposed release manager and schedule"):
On 19/08/2021 16:36, Ian Jackson wrote:
Can I at least get a +1 from someone for appointing me as RM
for 4.16 ? :-)
+1. Sorry I forgot to mention it in the previous e-
On 25.08.2021 14:12, Andrew Cooper wrote:
> On 24/08/2021 14:04, Jan Beulich wrote:
>> On 19.08.2021 18:26, Andrew Cooper wrote:
>>> In some configurations, it is safe to not overwrite the RSB on entry to Xen.
>>> Both Intel and AMD have guidelines in this area, because of the performance
>>> diffe
All,
the release is about due; I intend to only wait for XSA-384 to go
public in two weeks time. Please point out backports you find missing
from the respective staging branch, but which you consider relevant.
Jan
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
A NUMA aware device tree will provide a "distance-map" node to
describe distance between any two nodes. This patch introduce a
s/introduce/introduces/
new helper to parse this distance map.
Signed-off-by: Wei Chen
---
xen/arch/arm/numa_device_
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
Memory blocks' NUMA ID information is stored in device tree's
memory nodes as "numa-node-id". We need a new helper to parse
and verify this ID from memory nodes.
In order to support memory affinity in later use, the valid
memory ranges and NUMA ID wi
branch xen-4.15-testing
xenbranch xen-4.15-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
Hi Wei,
On 11/08/2021 11:24, Wei Chen wrote:
In later patches, we will parse CPU and memory NUMA information
from device tree. FDT is using device type property to indicate
CPU nodes and memory nodes. So we introduce fdt_node_check_type
in this patch to avoid redundant code in subsequent patches
On 25.08.2021 15:28, Julien Grall wrote:
> On 11/08/2021 11:23, Wei Chen wrote:
>> --- a/xen/include/asm-arm/numa.h
>> +++ b/xen/include/asm-arm/numa.h
>> @@ -5,7 +5,15 @@
>>
>> typedef u8 nodeid_t;
>>
>> -#if !defined(CONFIG_NUMA)
>> +#if defined(CONFIG_NUMA)
>> +
>> +/*
>> + * Same as x86
On 24/08/2021 15:15, Jan Beulich wrote:
> Both callers only care about the target (level 1) MFN. I also cannot
> see what we might need higher level MFNs for down the road. And even
> modern gcc doesn't recognize the optimization potential.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Coope
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
Today's Arm64 systems can reach or exceed 16 NUMA nodes, so
we set the number to 64 to match with x86.
Signed-off-by: Wei Chen
---
xen/include/asm-arm/numa.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/xen/includ
On 25/08/2021 12:15, Wei Chen wrote:
Hi Julien,
Hi Wei,
-Original Message-
From: Julien Grall
Sent: 2021年8月25日 18:22
To: Wei Chen ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org; jbeul...@suse.com
Cc: Bertrand Marquis
Subject: Re: [XEN RFC PATCH 12/40] xen/x86: Move numa
On 25/08/2021 13:07, Wei Chen wrote:
Hi Julien,
Hi Wei,
-Original Message-
From: Julien Grall
Sent: 2021年8月25日 18:37
To: Wei Chen ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org; jbeul...@suse.com
Cc: Bertrand Marquis
Subject: Re: [XEN RFC PATCH 13/40] xen/arm: introduce
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
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.
Signed-off-by: Bertrand Marquis
--
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
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
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
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 v3: none
Changes in v2: Rebase
---
xen/i
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
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 25.08.21 13:41, zhaoxiao wrote:
Since we have the nice helpers pr_err() and pr_warn(), use them instead
of raw printk().
Signed-off-by: zhaoxiao
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP d
On 25.08.21 08:24, 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
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Descriptio
On 25.08.21 08:22, 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
I already gave you feedback for another patch asking you to adjust
the continuati
Since we have the nice helpers pr_err() and pr_warn(), use them instead
of raw printk().
Signed-off-by: zhaoxiao
---
arch/x86/xen/platform-pci-unplug.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/xen/platform-pci-unplug.c
b/arch/x86/xen/platfo
Jan Beulich writes ("Re: [xen-4.12-testing bisection] complete
test-amd64-i386-xl-qemuu-ovmf-amd64"):
> > We are going to need to backport a commit from unstable. Either
> > aad7b5c11d51 ("tools/firmware/ovmf: Use OvmfXen platform file is exist")
> > (but has been reverted)
> > or
> >
On 24/08/2021 14:04, Jan Beulich wrote:
> On 19.08.2021 18:26, Andrew Cooper wrote:
>> In some configurations, it is safe to not overwrite the RSB on entry to Xen.
>> Both Intel and AMD have guidelines in this area, because of the performance
>> difference it makes for native kernels.
> I don't thi
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月25日 18:37
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 13/40] xen/arm: introduce numa_set_node for
> Arm
>
> Hi Wei,
>
On 24.08.2021 16:13, Jan Beulich wrote:
> For a long time we've been rather inefficient with IOMMU page table
> management when not sharing page tables, i.e. in particular for PV (and
> further specifically also for PV Dom0) and AMD (where nowadays we never
> share page tables). While up to about 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28698 / XSA-380
version 2
long running loops in grant table handling
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28700 / XSA-383
version 2
xen/arm: No memory limit for dom0less domUs
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28699 / XSA-382
version 2
inadequate grant-v2 status frames array bounds check
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28697 / XSA-379
version 2
grant table v2 status pages may remain accessible after de-allocation
UPDATES IN VERSION 2
Patches updated to fix a typo in a
In cpu_bringup() there is a call of preempt_disable() without a paired
preempt_enable(). This is not needed as interrupts are off initially.
Additionally this will result in early boot messages like:
BUG: scheduling while atomic: swapper/1/0/0x0002
Signed-off-by: Juergen Gross
---
arch/x86/
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月25日 18:22
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 12/40] xen/x86: Move numa_initmem_init to
> common
>
> Hi Wei,
flight 164409 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
This API is used to set one CPU to a NUMA node. If the system
configure NUMA off or system initialize NUMA failed, the
online NUMA node would set to only node#0. This will be done
in following patches. When NUMA turn off or init failed,
node_online_ma
Hi Stefan,
On Mon, Aug 23, 2021 at 10:58:46AM +0100, Stefan Hajnoczi wrote:
> 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
flight 164478 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164478/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen a931e8e64af07bd333a31f3b71a3f8f3e7910857
baseline version:
xen 9371
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
This function can be reused by Arm device tree based
NUMA support. So we move it from x86 to common, as well
as its related variables and functions:
setup_node_bootmem, numa_init_array and numa_emulation.
As numa_initmem_init has been moved to common
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Tue, 24 Aug 2021 12:28:05 +0200 you wrote:
> Xen backends of para-virtualized devices can live in dom0 kernel, dom0
> user land, or in a driver domain. This means that a backend might
> reside in a less trusted environm
We should not rely on guests to not use altp2m after reporting failure
of HVMOP_altp2m_set_domain_state to them. Set "active" back to false in
this case.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4609,6 +4609,8 @@ static int do_altp2m_op(
flight 164405 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164405/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 164309
test-amd64-amd64-qemuu-nested-amd 20
74 matches
Mail list logo
