On 8.02.2024 13:37, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
Multiple delays are required when sending IPIs and waiting for
responses. During boot, 4 such IPIs were sent per each AP. With this
change, only one set of broadcast IPIs is sent. This reduces boot time
On 8.02.2024 13:13, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
This will be used for parallel AP bring-up.
CPU_STATE_INIT changed direction.
Nit: I think you mean "changes" as you describe what the patch does, not
what has happened before. But ...
It was prev
On 8.02.2024 12:39, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
CPU id is obtained as a side effect of searching for appropriate
stack for AP. It can be used as a parameter to start_secondary().
Coincidentally this also makes further work on making AP bring-up
code parallel
On 8.02.2024 12:30, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
If multiple CPUs called machine_restart() before actual restart took
place, but after boot CPU declared itself not online,
Can you help me please in identifying where this operation is? I can see
two places
On 7.02.2024 18:02, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
It used to be called from smp_callin(), however BUG_ON() was invoked on
multiple occasions before that. It may end up calling machine_restart()
which tries to get APIC ID for CPU running this code. If BSP
On 5.02.2024 09:41, Jan Beulich wrote:
On 02.02.2024 19:24, Julien Grall wrote:
On 14/11/2023 17:50, Krystian Hebel wrote:
This location is easier to access from assembly. Having it close to
other data required during initialization has also positive (although
rather small) impact
On 8.02.2024 08:29, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
Both fields held the same data.
Supposedly the same data only. They come from different origins, and you're
hiding this quite well by leaving all sites in place where the field is
written. Both items are also
Hi,
On 7.02.2024 17:41, Jan Beulich wrote:
On 02.02.2024 19:11, Julien Grall wrote:
Hi,
On 14/11/2023 17:50, Krystian Hebel wrote:
Both fields held the same data.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 8 +---
xen/arch/x86/include/asm/asm_defns.h
On 7.02.2024 17:28, Jan Beulich wrote:
On 14.11.2023 18:49, Krystian Hebel wrote:
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -950,7 +950,7 @@ __next:
*/
if (boot_cpu_physical_apicid == -1U)
boot_cpu_physical_apicid = get_apic_id();
-x86_cpu_to_apicid[0
On 7.02.2024 17:11, Jan Beulich wrote:
On 14.11.2023 18:49, Krystian Hebel wrote:
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -72,6 +72,26 @@ trampoline_protmode_entry:
mov $X86_CR4_PAE,%ecx
mov %ecx,%cr4
Hi,
On 26.01.2024 19:30, Julien Grall wrote:
Hi,
I am not too familiary with the x86 boot code. But I will give a try
to review :).
On 14/11/2023 17:49, Krystian Hebel wrote:
This is made as first step of making parallel AP bring-up possible. It
should be enough for pre-C code.
Signed-off
Please ignore this series and review/reply to the other one
([XEN PATCH 0/9] x86: parallelize AP bring-up during boot) instead.
`git send-email` did what I asked it to do instead of what I wanted,
so I accidentally sent WIP version of patches.
Sorry for the noise.
--
Krystian Hebel
Firmware
possible, it is used for hotplug.
During wakeup from S3 APs are started one by one. It should be possible
to enable parallel execution there as well, but I don't have a way of
properly testing it as of now.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/include/asm/smp.h | 1 +
xen/arch/x86/setup.c
initialization.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/include/asm/cpufeature.h | 1 +
xen/arch/x86/smpboot.c| 80 ---
2 files changed, 49 insertions(+), 32 deletions(-)
diff --git a/xen/arch/x86/include/asm/cpufeature.h
b/xen/arch/x86/include/asm
CPU id is obtained as a side effect of searching for appropriate
stack for AP. It can be used as a parameter to start_secondary().
Coincidentally this also makes further work on making AP bring-up
code parallel easier.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 13
possible, it is used for hotplug.
During wakeup from S3 APs are started one by one. It should be possible
to enable parallel execution there as well, but I don't have a way of
properly testing it as of now.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/include/asm/smp.h | 1 +
xen/arch/x86/setup.c
against running out of stack, code checks if boot CPU is
still online before calling on_selected_cpus().
Signed-off-by: Krystian Hebel
---
xen/arch/x86/shutdown.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86
x2APIC on secondary CPUs earlier protects against an endless
loop of #GP exceptions caused by attempts to read IA32_X2APIC_APICID
MSR while x2APIC is disabled in IA32_APIC_BASE.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/smpboot.c | 9 -
1 file changed, 8 insertions(+), 1 deletion
x2APIC on secondary CPUs earlier protects against an endless
loop of #GP exceptions caused by attempts to read IA32_X2APIC_APICID
MSR while x2APIC is disabled in IA32_APIC_BASE.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/smpboot.c | 9 -
1 file changed, 8 insertions(+), 1 deletion
Both fields held the same data.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 8 +---
xen/arch/x86/include/asm/asm_defns.h | 2 +-
xen/arch/x86/include/asm/processor.h | 2 ++
xen/arch/x86/include/asm/smp.h | 4
xen/arch/x86/numa.c
possible, it is used for hotplug.
During wakeup from S3 APs are started one by one. It should be possible
to enable parallel execution there as well, but I don't have a way of
properly testing it as of now.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/include/asm/smp.h | 1 +
xen/arch/x86/setup.c
Both fields held the same data.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 8 +---
xen/arch/x86/include/asm/asm_defns.h | 2 +-
xen/arch/x86/include/asm/processor.h | 2 ++
xen/arch/x86/include/asm/smp.h | 4
xen/arch/x86/numa.c
initialization.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/include/asm/cpufeature.h | 1 +
xen/arch/x86/smpboot.c| 80 ---
2 files changed, 49 insertions(+), 32 deletions(-)
diff --git a/xen/arch/x86/include/asm/cpufeature.h
b/xen/arch/x86/include/asm
This is done in preparation to move data from x86_cpu_to_apicid[]
elsewhere.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/acpi/cpu_idle.c | 4 ++--
xen/arch/x86/acpi/lib.c | 2 +-
xen/arch/x86/apic.c | 2 +-
xen/arch/x86/cpu/mwait-idle.c | 4 ++--
xen/arch
This is made as first step of making parallel AP bring-up possible. It
should be enough for pre-C code.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/trampoline.S | 20
xen/arch/x86/boot/x86_64.S | 28 +++-
xen/arch/x86/setup.c
): 68.00%
Krystian Hebel (9):
x86/boot: choose AP stack based on APIC ID
x86: don't access x86_cpu_to_apicid[] directly, use
cpu_physical_id(cpu)
x86/smp: drop x86_cpu_to_apicid, use cpu_data[cpu].apicid instead
x86/smp: move stack_base to cpu_data
x86/smp: call x2apic_ap_setup() earlier
CPU id is obtained as a side effect of searching for appropriate
stack for AP. It can be used as a parameter to start_secondary().
Coincidentally this also makes further work on making AP bring-up
code parallel easier.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 13
This location is easier to access from assembly. Having it close to
other data required during initialization has also positive (although
rather small) impact on prefetching data from RAM.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S| 5 ++---
xen/arch/x86/include
against running out of stack, code checks if boot CPU is
still online before calling on_selected_cpus().
Signed-off-by: Krystian Hebel
---
xen/arch/x86/shutdown.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86
This is done in preparation to move data from x86_cpu_to_apicid[]
elsewhere.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/acpi/cpu_idle.c | 4 ++--
xen/arch/x86/acpi/lib.c | 2 +-
xen/arch/x86/apic.c | 2 +-
xen/arch/x86/cpu/mwait-idle.c | 4 ++--
xen/arch
initialization.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/include/asm/cpufeature.h | 1 +
xen/arch/x86/smpboot.c| 80 ---
2 files changed, 49 insertions(+), 32 deletions(-)
diff --git a/xen/arch/x86/include/asm/cpufeature.h
b/xen/arch/x86/include/asm
This is made as first step of making parallel AP bring-up possible. It
should be enough for pre-C code.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/trampoline.S | 20
xen/arch/x86/boot/x86_64.S | 28 +++-
xen/arch/x86/setup.c
From: Andrew Cooper
Before speculation defences, some paths in Xen could genuinely get away with
being IRQs-on at entry. But XPTI invalidated this property on most paths, and
attempting to maintain it on the remaining paths was a mistake.
Fast forward, and DO_SPEC_CTRL_COND_IBPB (protection
This location is easier to access from assembly. Having it close to
other data required during initialization has also positive (although
rather small) impact on prefetching data from RAM.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S| 5 ++---
xen/arch/x86/include
34 matches
Mail list logo
