On 10.01.2023 20:16, Oleksii wrote:
> Sorry for breaking into the conversation.
That's perfectly fine; no need to be sorry.
> On Tue, 2023-01-10 at 18:02 +0100, Jan Beulich wrote:
>> Arm maintainers,
>>
>> On 10.01.2023 16:17, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/inc
On 10/1/23 23:01, BALATON Zoltan wrote:
On Tue, 10 Jan 2023, Philippe Mathieu-Daudé wrote:
The 'hwaddr' type is defined in "exec/hwaddr.h" as:
hwaddr is the type of a physical address
(its size can be different from 'target_ulong').
All definitions use the 'HWADDR_' prefix, except TARGET_
On 20.12.22 20:42, Julien Grall wrote:
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
@@ -313,19 +302,19 @@ const char *dump_state_watches(FILE *fp, struct
connection *conn,
unsigned int conn_id)
{
const char *ret = NULL;
+ const char *watch_path;
s
On 20.12.22 20:39, Julien Grall wrote:
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
Instead of special casing the permission handling and watch event
firing for the special watch paths "@introduceDomain" and
"@releaseDomain", use static dummy nodes added to the data base when
starting
On 20.12.22 20:01, Julien Grall wrote:
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
When a domain has been released by Xen tools, remove all its
registered watches. This avoids sending watch events to the dead domain
when all the nodes related to it are being removed by the Xen tools.
flight 175716 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175716/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
flight 175715 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175715/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf c0f454c68329301447fd258e47824f7d402f19e9
baseline version:
xtf d1b8b7c312d2cf0e501ed4
flight 175706 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175706/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462
test-amd64-amd64-li
flight 175709 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175709/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
flight 175712 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175712/
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
flight 175711 ovmf real [real]
flight 175713 ovmf real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175711/
http://logs.test-lab.xenproject.org/osstest/logs/175713/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-
branch xen-unstable
xenbranch xen-unstable
job build-armhf
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem ch
On 10/01/2023 17:02, Jan Beulich wrote:
Arm maintainers,
Hi Jan,
On 10.01.2023 16:17, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/arch/riscv/include/asm/init.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_ASM_INIT_H
+#define _XEN_ASM_INIT_H
+
+#endif /* _XEN_ASM_INIT_H */
instead of having RISC-V in
On Wed, Jan 11, 2023 at 1:18 AM Oleksii Kurochko
wrote:
>
> The patch introduces and sets up a stack in order to go to C environment
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
Alistair
> ---
> Changes in V3:
> - reorder headers in alphabetical order
> - merge ch
On Tue, 10 Jan 2023, Philippe Mathieu-Daudé wrote:
The 'hwaddr' type is defined in "exec/hwaddr.h" as:
hwaddr is the type of a physical address
(its size can be different from 'target_ulong').
All definitions use the 'HWADDR_' prefix, except TARGET_FMT_plx:
$ fgrep define include/exec/hwa
The 'hwaddr' type is defined in "exec/hwaddr.h" as:
hwaddr is the type of a physical address
(its size can be different from 'target_ulong').
All definitions use the 'HWADDR_' prefix, except TARGET_FMT_plx:
$ fgrep define include/exec/hwaddr.h
#define HWADDR_H
#define HWADDR_BITS 64
#
flight 175694 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175694/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail in 175671 pass
in 175694
test-amd64-i386-xl-vhd
flight 175703 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
flight 175707 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175707/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ec54ce1f1ab41b92782b37ae59e752fff0ef9c41
baseline version:
ovmf 717f35a9f2d883a74998f
Hello Jan,
Sorry for breaking into the conversation.
On Tue, 2023-01-10 at 18:02 +0100, Jan Beulich wrote:
> Arm maintainers,
>
> On 10.01.2023 16:17, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/init.h
> > @@ -0,0 +1,12 @@
> > +#ifndef _XEN_ASM_INIT_H
> > +#def
On 10/01/2023 5:18 pm, Andrew Cooper wrote:
> Have guest_{rd,wr}msr(), via hvm_{get,set}_reg(), access either the live
> register, or stashed state, depending on context. Include MSR_PKRS for
> migration, and let the guest have full access.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beul
WRMSR Non-Serialising is an optimisation intended for cases where an MSR needs
updating, but architectural serialising properties are not needed.
In is anticipated that this will apply to most if not all MSRs modified on
context switch paths.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC:
With all infrastructure in place, advertise the PKS CPUID bit to HAP guests,
and let them set CR4.PKS.
Experiment with a tweak to the layout of hvm_cr4_guest_valid_bits() so future
additions will be just a single added line.
The current context switching behaviour is tied to how VT-x works, so le
PKS is very similar to the existing PKU behaviour, operating on pagewalks for
any supervisor mapping.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/include/asm/guest_pt.h | 5 +
xen/arch/x86/include/asm/hvm/hvm.
Protection Key Supervisor works in a very similar way to Protection Key User,
except that instead of a PKRU register used by the {RD,WR}PKRU instructions,
the supervisor protection settings live in MSR_PKRS and is accessed using
normal {RD,WR}MSR instructions.
PKS has the same problematic interact
Under PKS, MSR_PKRS is available and based on the CPUID policy alone, and
usable independently of CR4.PKS. See the large comment in prot-key.h for
details of the context switching arrangement.
Use WRMSRNS right away, as we don't care about serialsing properties for
context switching this MSR.
Sa
While the reset value of the register is 0, it might not be after kexec/etc.
If PKEY0.{WD,AD} have leaked in from an earlier context, construction of a PV
dom0 will explode.
Sequencing wise, this must come after setting CR4.PKE, and before we touch any
user mappings.
Signed-off-by: Andrew Cooper
asm/processor.h is in desperate need of splitting up, and protection key
functionality in only used in the emulator and pagewalk. Introduce a new
asm/prot-key.h and move the relevant content over.
Rename the PKRU_* constants to drop the user part and to use the architectural
terminology.
Drop th
Only 14 months after v1... This time with testing on real hardware (not that
any bugs were found) and against an updated XTF comprehensive pagewalk test.
# time ./xtf-runner hvm64 pagetable-emulation~hap
--- Xen Test Framework ---
Environment: HVM 64bit (Long mode 4 levels)
Test pagetable
Have guest_{rd,wr}msr(), via hvm_{get,set}_reg(), access either the live
register, or stashed state, depending on context. Include MSR_PKRS for
migration, and let the guest have full access.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei
flight 175689 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175689/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462
test-amd64-amd64-li
Arm maintainers,
On 10.01.2023 16:17, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/init.h
> @@ -0,0 +1,12 @@
> +#ifndef _XEN_ASM_INIT_H
> +#define _XEN_ASM_INIT_H
> +
> +#endif /* _XEN_ASM_INIT_H */
instead of having RISC-V introduce an empty stub matching what x86 h
On 10.01.2023 16:17, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> Changes in V3:
> - Nothing changed
> ---
> Changes in V2:
> - Remove unneeded now types from
I guess you went a little too far: Types used in common code, even if you
do not build that yet, will want d
On 10.01.2023 09:49, Wei Chen wrote:
> --- a/xen/arch/arm/include/asm/numa.h
> +++ b/xen/arch/arm/include/asm/numa.h
> @@ -28,6 +28,20 @@ enum dt_numa_status {
> DT_NUMA_OFF,
> };
>
> +/*
> + * In ACPI spec, 0-9 are the reserved values for node distance,
> + * 10 indicates local node distan
On 10.01.2023 09:49, Wei Chen wrote:
> --- a/xen/arch/arm/include/asm/numa.h
> +++ b/xen/arch/arm/include/asm/numa.h
> @@ -22,6 +22,12 @@ typedef u8 nodeid_t;
> */
> #define NR_NODE_MEMBLKS NR_MEM_BANKS
>
> +enum dt_numa_status {
> +DT_NUMA_INIT,
I don't see any use of this. I also think
flight 175702 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175702/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 717f35a9f2d883a74998f7deb3d2cdf95bddf039
baseline version:
ovmf 82dd766f25225b0812bba
On 09.01.2023 13:08, Andrew Cooper wrote:
> Ice Lake (server at least) has both Arch LBR and model-specific LBR. Sapphire
> Rapids does not have model-specific LBR at all. I.e. On SPR and later,
> model_specific_lbr will always be NULL, so we must make changes to avoid
> reliably hitting the doma
On 10/01/2023 4:26 pm, Jan Beulich wrote:
> On 09.01.2023 13:08, Andrew Cooper wrote:
>> There is no point repeating this calculation at runtime, especially as it is
>> in the fallback path of the WRSMR/RDMSR handlers.
>>
>> Move the infrastructure higher in vmx.c to avoid forward declarations,
>>
On 09.01.2023 13:08, Andrew Cooper wrote:
> There is no point repeating this calculation at runtime, especially as it is
> in the fallback path of the WRSMR/RDMSR handlers.
>
> Move the infrastructure higher in vmx.c to avoid forward declarations,
> renaming last_branch_msr_get() to get_model_spec
All RISCV_64-related stuff was renamed to be consistent with
ARM (arm32 is cross build as RISCV_64).
The patch is based on the following patch series:
[PATCH *] Basic early_printk and smoke test implementation
Signed-off-by: Oleksii Kurochko
---
...v64.dockerfile => current-riscv64.dockerfile}
On 10.01.2023 16:17, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/Kconfig.debug
> +++ b/xen/arch/riscv/Kconfig.debug
> @@ -0,0 +1,7 @@
> +config EARLY_PRINTK
> +bool "Enable early printk"
> +default DEBUG
> +depends on RISCV_64 || RISCV_32
You're in a RISC-V-specific Kconfig - do you
On Tue, Jan 10, 2023 at 10:25 AM Anthony PERARD
wrote:
>
> The configure option "--enable-trace-backend" isn't accepted anymore
> and we should use "--enable-trace-backends" instead which was
> introduce in 2014 and allow multiple backends.
>
> "--enable-trace-backends" was introduced by:
> 5b
The configure option "--enable-trace-backend" isn't accepted anymore
and we should use "--enable-trace-backends" instead which was
introduce in 2014 and allow multiple backends.
"--enable-trace-backends" was introduced by:
5b808275f3bb ("trace: Multi-backend tracing")
The backward compatible o
Add check if there is a message 'Hello from C env' presents
in log file to be sure that stack is set and C part of early printk
is working.
Signed-off-by: Oleksii Kurochko
Acked-by: Stefano Stabellini
---
Changes in V3:
- Nothing changed
- All mentioned comments by Stefano in Xen mailing
From: Bobby Eshleman
Originally SBI implementation for Xen was introduced by
Bobby Eshleman but it was removed
all the stuff for simplicity except SBI call for putting
character to console.
The patch introduces sbi_putchar() SBI call which is necessary
to implement initial early_printk.
Signe
The patch introduces and sets up a stack in order to go to C environment
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- reorder headers in alphabetical order
- merge changes related to start_xen() function from "[PATCH v2 7/8]
xen/riscv: print hello message from C env" to this
The following patches require which includes
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- Nothing changed
---
Changes in V2:
- Add explanation comment to the comment message
---
xen/arch/riscv/include/asm/init.h | 12
1 file changed, 12 insertions(+)
create mode 1
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- Nothing changed
---
Changes in V2:
- Remove unneeded now types from
---
xen/arch/riscv/include/asm/types.h | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 xen/arch/riscv/include/asm/types.h
diff --git
From: Bobby Eshleman
The patch introduces a basic stuff of early_printk functionality
which will be enough to print 'hello from C environment".
early_printk() function was changed in comparison with original as
common isn't being built now so there is no vscnprintf.
Because printk() relies on a
The patch series introduces the following:
- the minimal set of headers and changes inside them.
- SBI (RISC-V Supervisor Binary Interface) things necessary for basic
early_printk implementation.
- things needed to set up the stack.
- early_printk() function to print only strings.
- RISC-V smoke
flight 175691 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175691/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
>> Hello,
>>
I'm trying to measure the performance of Xen on the S32G3 microprocessor,
unfortunately, after following the BSP-Linux to install Xen, I found that
Xentrace is not available or not compatible with ARM architecture. I have seen
some studies on Xilinx, and how they made Xentrace com
On 10/01/2023 1:33 pm, Tushar Goel wrote:
> Hey,
>
> We would like to integrate the xen security data[1][2] data
> in vulnerablecode[3] which is a FOSS db of FOSS vulnerability data.
> We were not able to know under which license this security data comes.
> We would be grateful to have your acknowl
Hey,
We would like to integrate the xen security data[1][2] data
in vulnerablecode[3] which is a FOSS db of FOSS vulnerability data.
We were not able to know under which license this security data comes.
We would be grateful to have your acknowledgement over
usage of the xen security data in vulne
On 1/10/2023 3:16 AM, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote:
> > Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
> > as noted in docs/igd-assign.txt in the Qemu source code.
> >
> > Currently, when the xl toolstack is use
Hi Penny,
On 10/01/2023 03:38, Penny Zheng wrote:
-Original Message-
From: Julien Grall
Sent: Tuesday, January 10, 2023 2:23 AM
To: Penny Zheng ; xen-devel@lists.xenproject.org
Cc: Wei Chen ; Stefano Stabellini
; Bertrand Marquis ;
Volodymyr Babchuk
Subject: Re: [PATCH v1 06/13] xen/ar
(+ George)
On 10/01/2023 12:43, Julien Grall wrote:
On 10/01/2023 08:21, Oleksii wrote:
Hi,
Hi Oleksii,
On Mon, 2023-01-09 at 16:03 +, Julien Grall wrote:
Hi,
On 09/01/2023 15:46, Oleksii Kurochko wrote:
The patch introduce sbi_putchar() SBI call which is necessary
to implement ini
On 10/01/2023 08:21, Oleksii wrote:
Hi,
Hi Oleksii,
On Mon, 2023-01-09 at 16:03 +, Julien Grall wrote:
Hi,
On 09/01/2023 15:46, Oleksii Kurochko wrote:
The patch introduce sbi_putchar() SBI call which is necessary
to implement initial early_printk
Signed-off-by: Oleksii Kurochko
-
On 09.01.23 11:36, Oleksandr Tyshchenko wrote:
>
>
> On 08.01.23 18:06, Julien Grall wrote:
>
> Hello Julien, Ayan, all
>
>> Hi Ayan,
>> ...
>> The changes look good to me (with a few of comments below). That
>> said, before acking the code, I would like an existing user of uImage
>> (maybe EPAM
flight 175684 libvirt real [real]
flight 175698 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175684/
http://logs.test-lab.xenproject.org/osstest/logs/175698/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-li
branch xen-unstable
xenbranch xen-unstable
job build-arm64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem ch
On Tue, Jan 10, 2023 at 5:29 PM Bobby Eshleman wrote:
>
>
>
> On Mon, Jan 9, 2023 at 4:28 PM Alistair Francis wrote:
>>
>> On Tue, Jan 10, 2023 at 1:47 AM Oleksii Kurochko
>> wrote:
>> >
>> > The patch introduces a basic stuff of early_printk functionality
>> > which will be enough to print 'hel
On 10.01.2023 09:49, Wei Chen wrote:
> Current numa command in documentation is x86 only. Remove
> x86 from numa command's arch limitation in this patch.
>
> Signed-off-by: Wei Chen
Acked-by: Jan Beulich
Of course not on its own, only on top of all the earlier patches.
Jan
On 10.01.23 10:38, Jan Beulich wrote:
On 10.01.2023 06:59, Juergen Gross wrote:
On 10.01.23 06:47, Juergen Gross wrote:
On 09.01.23 19:28, Michael Kelley (LINUX) wrote:
I've come across a case with a VM running on Hyper-V that doesn't get
MTRRs, but the PAT is functional. (This is a Confident
On 10.01.2023 09:49, Wei Chen wrote:
> --- a/xen/arch/arm/include/asm/numa.h
> +++ b/xen/arch/arm/include/asm/numa.h
> @@ -3,9 +3,26 @@
>
> #include
>
> +#include
> +
> typedef u8 nodeid_t;
>
> -#ifndef CONFIG_NUMA
> +#ifdef CONFIG_NUMA
> +
> +/*
> + * It is very likely that if you have m
On 10.01.2023 06:59, Juergen Gross wrote:
> On 10.01.23 06:47, Juergen Gross wrote:
>> On 09.01.23 19:28, Michael Kelley (LINUX) wrote:
>>> I've come across a case with a VM running on Hyper-V that doesn't get
>>> MTRRs, but the PAT is functional. (This is a Confidential VM using
>>> AMD's SEV-SNP
flight 175671 xen-unstable real [real]
flight 175692 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175671/
http://logs.test-lab.xenproject.org/osstest/logs/175692/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
The NUMA information provided in the host Device-Tree
are only for Xen. For dom0, we want to hide them as they
may be different (for now, dom0 is still not aware of NUMA)
The CPU and memory nodes are recreated from scratch for the
domain. So we already skip the "numa-node-id" property for
these two
A NUMA aware device tree will provide a "distance-map" node to
describe distance between any two nodes. This patch introduce a
new helper to parse this distance map.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Get rid of useless braces.
2. Use new NUMA status helper.
3. Use PRIu32 to replace u in pr
node_online_map in smpboot still need for Arm when NUMA is turn
off by Kconfig.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. No change.
---
xen/arch/arm/smpboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 5ee6ab11e9..3ae359bbeb 100644
Processor NUMA ID information is stored in device tree's processor
node as "numa-node-id". We need a new helper to parse this ID from
processor node. If we get this ID from processor node, this ID's
validity still need to be checked. Once we got a invalid NUMA ID
from any processor node, the device
Arm platforms support both ACPI and device tree. We don't
want users to select device tree NUMA or ACPI NUMA manually.
We hope users can just enable NUMA for Arm, and device tree
NUMA and ACPI NUMA can be selected depends on device tree
feature and ACPI feature status automatically. In this case,
t
Device tree based NUMA doesn't have the proximity domain like
ACPI. So we can return node id directly as arch nid.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Use numa_node_to_arch_nid instead of dummy node_to_pxm.
---
xen/arch/arm/include/asm/numa.h | 9 +
1 file changed, 9 insertions(+)
From: Henry Wang
In the common sysctl command XEN_SYSCTL_physinfo, the cores_per_socket
is calculated based on the cpu_core_mask of CPU0. Currently on Arm
this is a fixed value 1 (can be checked via xl info), which is not
correct. This is because during the Arm cpu online process,
set_cpu_sibling
Current numa command in documentation is x86 only. Remove
x86 from numa command's arch limitation in this patch.
Signed-off-by: Wei Chen
---
v1 -> v2:
1. Update Arm NUMA status in SUPPORT.md to "Tech Preview".
---
SUPPORT.md| 1 +
docs/misc/xen-command-line.pandoc | 2 +-
In this patch, we can start to create NUMA system that is
based on device tree.
Signed-off-by: Wei Chen
---
v1->v2:
1. replace ~0 by INVALID_PADDR.
2. only print error messages for invalid dtb data.
3. remove unnecessary return.
4. remove the parameter of numa_init.
---
xen/arch/arm/include/asm/
We will parse NUMA nodes distances from device tree. So we need
a matrix to record the distances between any two nodes we parsed.
Accordingly, we provide this node_set_distance API for device tree
NUMA to set the distance for any two nodes in this patch. When
NUMA initialization failed, __node_dist
In this function, we scan the whole device tree to parse CPU node id,
memory node id and distance-map. Though early_scan_node will invoke
a handler to process memory nodes. If we want to parse memory node id
in that handler, we have to embed NUMA parse code in that handler.
But we still need to sca
In this patch, we make NUMA node online and add cpu to
its NUMA node. This will make NUMA-aware components
have NUMA affinity data to support their work.
To keep the mostly the same behavior of x86, we use
numa_detect_cpu_node to online node. The difference is that,
we have prepared cpu_to_node in
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.
Signed-off-by: Wei Chen
---
v1->v2:
1. Move numa_disabled check to fdt_parse_numa_memory_node.
2. Use numa_bad to replace bad_srat.
3.
NUMA implementation has a cpu_to_node array to store CPU to NODE
map. Xen is using CPU logical ID in runtime components, so we
use CPU logical ID as CPU index in cpu_to_node.
In device tree case, cpu_logical_map is created in dt_smp_init_cpus.
So, when NUMA is enabled, dt_smp_init_cpus will fetch
As a memory range described in device tree cannot be split across
multiple nodes. And it is very likely than if you have more than
64 nodes, you may need a lot more than 2 regions per node. So the
default NR_NODE_MEMBLKS value (MAX_NUMNODES * 2) makes no sense
on Arm.
So, for Arm, we would just de
NUMA has one global and one implementation specific switches. For
ACPI NUMA implementation, Xen has acpi_numa, so we introduce
device_tree_numa for device tree NUMA implementation. And use
enumerations to indicate init, off and on status.
arch_numa_disabled will get device_tree_numa status, but fo
Implement the same helper "arch_get_ram_range" as x86 for NUMA
code to get memory bank from Arm bootinfo.
Signed-off-by: Wei Chen
---
v2 -> v3:
1. Use arch_get_ram_range instead of arch_get_memory_map.
v1 -> v2:
1. Use arch_get_memory_map to replace arch_get_memory_bank_range
and arch_get_memo
(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 cod
flight 175686 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175686/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 82dd766f25225b0812bbac628c60d2b48f2346e4
baseline version:
ovmf 2cc6d4c8ed54e36fd9638
On Mon, 2023-01-09 at 16:11 +, Julien Grall wrote:
> Hi,
>
> On 09/01/2023 15:46, Oleksii Kurochko wrote:
> > The patch introduces and sets up a stack in order to go to C
> > environment
> >
> > Signed-off-by: Oleksii Kurochko
>
> It looks like the comments from Andrew were missed.
>
I wil
Hi,
On Mon, 2023-01-09 at 16:03 +, Julien Grall wrote:
> Hi,
>
> On 09/01/2023 15:46, Oleksii Kurochko wrote:
> > The patch introduce sbi_putchar() SBI call which is necessary
> > to implement initial early_printk
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V2:
> > -
On Mon, 2023-01-09 at 17:00 +0100, Jan Beulich wrote:
> On 09.01.2023 16:46, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/sbi.h
> > @@ -0,0 +1,34 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-or-later) */
> > +/*
> > + * Copyright (c) 2021 Vates SAS.
> > + *
> > + *
On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote:
> Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
> as noted in docs/igd-assign.txt in the Qemu source code.
>
> Currently, when the xl toolstack is used to configure a Xen HVM guest with
> Intel IGD passthroug
On Mon, 2023-01-09 at 18:21 -0800, Stefano Stabellini wrote:
> On Mon, 9 Jan 2023, Oleksii Kurochko wrote:
> > Add check if there is a message 'Hello from C env' presents
> > in log file to be sure that stack is set and C part of early printk
> > is working.
> >
> > Signed-off-by: Oleksii Kurochko
On 05.01.23 10:01, Jiapeng Chong wrote:
The function p2m_index is defined in the p2m.c file, but not called
elsewhere, so remove this unused function.
arch/x86/xen/p2m.c:137:24: warning: unused function 'p2m_index'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3557
Reported-by: Abaci Ro
On 20.12.22 15:50, Oleksii Moisieiev wrote:
Data buffer for active map is allocated in alloc_active_ring and freed
in free_active_ring function, which is used only for the error
cleanup. pvcalls_front_release is calling pvcalls_front_free_map which
ends foreign access for this buffer, but doesn't
On 13.12.22 16:46, Dawei Li wrote:
Since commit fc7a6209d571 ("bus: Make remove callback return void")
forces bus_type::remove be void-returned, it doesn't make much sense for
any bus based driver implementing remove callbalk to return non-void to
its caller.
This change is for xen bus based dri
On 30.11.22 17:36, Roger Pau Monne wrote:
The currently lockless access to the xen console list in
vtermno_to_xencons() is incorrect, as additions and removals from the
list can happen anytime, and as such the traversal of the list to get
the private console data for a given termno needs to happe
flight 175681 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175681/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
96 matches
Mail list logo
