Re: Trying add smt=off disabled cores to cpupool crash xen
On 05.12.2023 18:24, René Winther Højgaard wrote: > You are right about sched-gran=core being the issue. > > I don't know if this is relevant, but my CPU shouldn't be able to use > sched-gran=core it's asymmetric. > > smt=on with sched-gran=core gives me a warning that it's falling back to > sched-gran=cpu, I tested smt=off with sched-gran=cpu and it works. > > This warning is missing with sched-gran=core and smt=off > > (XEN) *** > (XEN) Asymmetric cpu configuration. > (XEN) Falling back to sched-gran=cpu. > (XEN) *** And (presumably) rightly so, because at the core level (presumably) there is no asymmetry. Jan
Re: Trying add smt=off disabled cores to cpupool crash xen
You are right about sched-gran=core being the issue. I don't know if this is relevant, but my CPU shouldn't be able to use sched-gran=core it's asymmetric. smt=on with sched-gran=core gives me a warning that it's falling back to sched-gran=cpu, I tested smt=off with sched-gran=cpu and it works. This warning is missing with sched-gran=core and smt=off (XEN) *** (XEN) Asymmetric cpu configuration. (XEN) Falling back to sched-gran=cpu. (XEN) *** /rene On Tuesday, December 5th, 2023 at 07:21, Juergen Gross wrote: > On 04.12.23 18:40, René Winther Højgaard wrote: > > > Hi Juergen, > > > > Sorry for the late reply. > > > > Here are the commands I execute, it is 'xl cpupool-cpu-add pcores 4-15' > > that crash the system. > > > > xl cpupool-cpu-remove Pool-0 4-31 > > xl cpupool-create name=\"ecores\" sched=\"credit\" > > xl cpupool-cpu-add ecores 16-31 > > > > xl cpupool-create name=\"pcores\" sched=\"credit\" > > xl cpupool-cpu-add pcores 4-15 > > > > Here is the other information you asked for. > > > > xl cpupool-list: > > Name CPUs Sched Active Domain count > > Pool-0 24 credit y 5 > > > > xl cpupool-list -c: > > Name CPU list > > Pool-0 0,2,4,6,8,10,12,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 > > > > xl info: > > host : dom0 > > release : 6.1.62-1.qubes.fc37.x86_64 > > version : #1 SMP PREEMPT_DYNAMIC Tue Nov 14 06:16:38 GMT 2023 > > machine : x86_64 > > nr_cpus : 24 > > max_cpu_id : 31 > > nr_nodes : 1 > > cores_per_socket : 24 > > threads_per_core : 1 > > cpu_mhz : 2995.196 > > hw_caps : > > bfebfbff:77faf3ff:2c100800:0121:000f:239c27eb:1840078c:0100 > > virt_caps : pv hvm hvm_directio pv_directio hap iommu_hap_pt_share vmtrace > > gnttab-v1 > > total_memory : 65373 > > free_memory : 56505 > > sharing_freed_memory : 0 > > sharing_used_memory : 0 > > outstanding_claims : 0 > > free_cpus : 0 > > xen_major : 4 > > xen_minor : 17 > > xen_extra : .2 > > xen_version : 4.17.2 > > xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 > > > > xen_scheduler : credit > > xen_pagesize : 4096 > > platform_params : virt_start=0x8000 > > xen_changeset : > > > > xen_commandline : placeholder dom0_mem=min:2048M dom0_mem=max:4096M > > ucode=scan gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 smt=off > > dom0_max_vcpus=4 dom0_vcpus_pin sched-gran=core sched=credit no-real-mode > > edd=off > > > Please drop the "sched-gran=core" from the Xen boot parameters. It doesn't > make > any sense with smt=off and is adding additional complexity. > > It shouldn't crash, but core scheduling is still "Experimental". I'll look > into > the issue later. > > > Juergen publickey - renewin@proton.me - 0x43C32E54.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Trying add smt=off disabled cores to cpupool crash xen
On 04.12.23 18:40, René Winther Højgaard wrote: Hi Juergen, Sorry for the late reply. Here are the commands I execute, it is 'xl cpupool-cpu-add pcores 4-15' that crash the system. xl cpupool-cpu-remove Pool-0 4-31 xl cpupool-create name=\"ecores\" sched=\"credit\" xl cpupool-cpu-add ecores 16-31 xl cpupool-create name=\"pcores\" sched=\"credit\" xl cpupool-cpu-add pcores 4-15 Here is the other information you asked for. xl cpupool-list: Name CPUs Sched Active Domain count Pool-0 24credit y 5 xl cpupool-list -c: Name CPU list Pool-0 0,2,4,6,8,10,12,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 xl info: host : dom0 release: 6.1.62-1.qubes.fc37.x86_64 version: #1 SMP PREEMPT_DYNAMIC Tue Nov 14 06:16:38 GMT 2023 machine: x86_64 nr_cpus: 24 max_cpu_id : 31 nr_nodes : 1 cores_per_socket : 24 threads_per_core : 1 cpu_mhz: 2995.196 hw_caps: bfebfbff:77faf3ff:2c100800:0121:000f:239c27eb:1840078c:0100 virt_caps : pv hvm hvm_directio pv_directio hap iommu_hap_pt_share vmtrace gnttab-v1 total_memory : 65373 free_memory: 56505 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 17 xen_extra : .2 xen_version: 4.17.2 xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : xen_commandline: placeholder dom0_mem=min:2048M dom0_mem=max:4096M ucode=scan gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 smt=off dom0_max_vcpus=4 dom0_vcpus_pin sched-gran=core sched=credit no-real-mode edd=off Please drop the "sched-gran=core" from the Xen boot parameters. It doesn't make any sense with smt=off and is adding additional complexity. It shouldn't crash, but core scheduling is still "Experimental". I'll look into the issue later. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Trying add smt=off disabled cores to cpupool crash xen
Hi Juergen, Sorry for the late reply. Here are the commands I execute, it is 'xl cpupool-cpu-add pcores 4-15' that crash the system. xl cpupool-cpu-remove Pool-0 4-31 xl cpupool-create name=\"ecores\" sched=\"credit\" xl cpupool-cpu-add ecores 16-31 xl cpupool-create name=\"pcores\" sched=\"credit\" xl cpupool-cpu-add pcores 4-15 Here is the other information you asked for. xl cpupool-list: Name CPUs Sched Active Domain count Pool-0 24credit y 5 xl cpupool-list -c: Name CPU list Pool-0 0,2,4,6,8,10,12,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 xl info: host : dom0 release: 6.1.62-1.qubes.fc37.x86_64 version: #1 SMP PREEMPT_DYNAMIC Tue Nov 14 06:16:38 GMT 2023 machine: x86_64 nr_cpus: 24 max_cpu_id : 31 nr_nodes : 1 cores_per_socket : 24 threads_per_core : 1 cpu_mhz: 2995.196 hw_caps: bfebfbff:77faf3ff:2c100800:0121:000f:239c27eb:1840078c:0100 virt_caps : pv hvm hvm_directio pv_directio hap iommu_hap_pt_share vmtrace gnttab-v1 total_memory : 65373 free_memory: 56505 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 17 xen_extra : .2 xen_version: 4.17.2 xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : xen_commandline: placeholder dom0_mem=min:2048M dom0_mem=max:4096M ucode=scan gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 smt=off dom0_max_vcpus=4 dom0_vcpus_pin sched-gran=core sched=credit no-real-mode edd=off cc_compiler: gcc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1) cc_compile_by : mockbuild cc_compile_domain : [unknown] cc_compile_date: Tue Nov 14 00:00:00 UTC 2023 build_id : a426597e4f24a9487bed72dafc63d4eb523be22b xend_config_format : 4 I'm not sure which file is the cpupool config file, this is the content from /etc/xen/cpupool # the name of the new cpupool name = "Example-Cpupool" # the scheduler to use: valid are e.g. credit, credit2 and rtds sched = "credit" # list of cpus to use cpus = ["2", "3"] /rene On Monday, December 4th, 2023 at 13:07, Juergen Gross wrote: > On 04.12.23 11:13, Jan Beulich wrote: > > > On 04.12.2023 11:02, Juergen Gross wrote: > > > > > On 04.12.23 10:15, Jan Beulich wrote: > > > > > > > On 01.12.2023 21:12, Andrew Cooper wrote: > > > > > > > > > On 01/12/2023 7:59 pm, René Winther Højgaard wrote: > > > > > > > > > > > If I set smt=off and try to configure cpupools with credit(1) as if > > > > > > all cores are available, I get the following crash. > > > > > > > > > > > > The crash happens when I try to use xl cpupool-add-cpu on the > > > > > > disabled > > > > > > HT sibling cores. > > > > > > > > > > > > Hyper-threading is enabled in the firmware, and only disabled with > > > > > > smt=off. > > > > > > > > > > CC'ing some maintainers. > > > > > > > > > > I expect this will also explode when a CPU is runtime offlined with > > > > > `xen-hptool cpu-offline` and then added to a cpupool. > > > > > > > > > > Interestingly, the crash is mov (%rdx,%rax,1),%r13, and I think that's > > > > > the percpu posion value in %rdx. > > > > > > > > > > I expect cpupools want to reject parked/offline CPUs. > > > > > > > > While the only explicit check there is > > > > > > > > if ( cpu >= nr_cpu_ids ) > > > > goto addcpu_out; > > > > > > > > I would have expected this > > > > > > > > if ( !cpumask_subset(cpus, _free_cpus) || > > > > cpumask_intersects(cpus, _locked_cpus) ) > > > > goto addcpu_out; > > > > > > > > to deal with the situation, as parked/offline CPUs shouldn't be "free". > > > > Jürgen? > > > > > > The problem is the call of sched_get_opt_cpumask() to need the percpu area > > > of the cpu in question. > > > > That was my first thought, too, but then I saw cpupool_assign_cpu_locked() > > on > > the call trace, which is called only afterwards. Plus > > sched_get_opt_cpumask() > > needs the per-CPU area only when granularity was switched from its default > > of > > SCHED_GRAN_cpu afaics. > > > Oh right you are. > > My patch is needed for larger granularities, though. > > I've tried to hit the same problem as René, but everything works as intended > (no > crash, but adding an offline cpu is being rejected). > > René, could you please tell us what exactly you've been doing? This would be: > > - Xen command line parameters > - Output of "xl info" > - Output of "xl cpupool-list" before starting to manipulate cpupools > - Output of "xl cpupool-list
Re: Trying add smt=off disabled cores to cpupool crash xen
On 04.12.23 11:13, Jan Beulich wrote: On 04.12.2023 11:02, Juergen Gross wrote: On 04.12.23 10:15, Jan Beulich wrote: On 01.12.2023 21:12, Andrew Cooper wrote: On 01/12/2023 7:59 pm, René Winther Højgaard wrote: If I set smt=off and try to configure cpupools with credit(1) as if all cores are available, I get the following crash. The crash happens when I try to use xl cpupool-add-cpu on the disabled HT sibling cores. Hyper-threading is enabled in the firmware, and only disabled with smt=off. CC'ing some maintainers. I expect this will also explode when a CPU is runtime offlined with `xen-hptool cpu-offline` and then added to a cpupool. Interestingly, the crash is mov (%rdx,%rax,1),%r13, and I think that's the percpu posion value in %rdx. I expect cpupools want to reject parked/offline CPUs. While the only explicit check there is if ( cpu >= nr_cpu_ids ) goto addcpu_out; I would have expected this if ( !cpumask_subset(cpus, _free_cpus) || cpumask_intersects(cpus, _locked_cpus) ) goto addcpu_out; to deal with the situation, as parked/offline CPUs shouldn't be "free". Jürgen? The problem is the call of sched_get_opt_cpumask() to need the percpu area of the cpu in question. That was my first thought, too, but then I saw cpupool_assign_cpu_locked() on the call trace, which is called only afterwards. Plus sched_get_opt_cpumask() needs the per-CPU area only when granularity was switched from its default of SCHED_GRAN_cpu afaics. Oh right you are. My patch is needed for larger granularities, though. I've tried to hit the same problem as René, but everything works as intended (no crash, but adding an offline cpu is being rejected). René, could you please tell us what exactly you've been doing? This would be: - Xen command line parameters - Output of "xl info" - Output of "xl cpupool-list" before starting to manipulate cpupools - Output of "xl cpupool-list -c" before starting to manipulate cpupools - Cpupool config file used to create new cpupool - xl commands you've used to setup the cpupool and adding the cpu(s) to it Thanks, Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Trying add smt=off disabled cores to cpupool crash xen
On 04.12.2023 11:02, Juergen Gross wrote: > On 04.12.23 10:15, Jan Beulich wrote: >> On 01.12.2023 21:12, Andrew Cooper wrote: >>> On 01/12/2023 7:59 pm, René Winther Højgaard wrote: If I set smt=off and try to configure cpupools with credit(1) as if all cores are available, I get the following crash. The crash happens when I try to use xl cpupool-add-cpu on the disabled HT sibling cores. Hyper-threading is enabled in the firmware, and only disabled with smt=off. >>> >>> CC'ing some maintainers. >>> >>> I expect this will also explode when a CPU is runtime offlined with >>> `xen-hptool cpu-offline` and then added to a cpupool. >>> >>> Interestingly, the crash is mov (%rdx,%rax,1),%r13, and I think that's >>> the percpu posion value in %rdx. >>> >>> I expect cpupools want to reject parked/offline CPUs. >> >> While the only explicit check there is >> >> if ( cpu >= nr_cpu_ids ) >> goto addcpu_out; >> >> I would have expected this >> >> if ( !cpumask_subset(cpus, _free_cpus) || >> cpumask_intersects(cpus, _locked_cpus) ) >> goto addcpu_out; >> >> to deal with the situation, as parked/offline CPUs shouldn't be "free". >> Jürgen? > > The problem is the call of sched_get_opt_cpumask() to need the percpu area > of the cpu in question. That was my first thought, too, but then I saw cpupool_assign_cpu_locked() on the call trace, which is called only afterwards. Plus sched_get_opt_cpumask() needs the per-CPU area only when granularity was switched from its default of SCHED_GRAN_cpu afaics. Jan
Re: Trying add smt=off disabled cores to cpupool crash xen
On 04.12.23 10:15, Jan Beulich wrote: On 01.12.2023 21:12, Andrew Cooper wrote: On 01/12/2023 7:59 pm, René Winther Højgaard wrote: If I set smt=off and try to configure cpupools with credit(1) as if all cores are available, I get the following crash. The crash happens when I try to use xl cpupool-add-cpu on the disabled HT sibling cores. Hyper-threading is enabled in the firmware, and only disabled with smt=off. CC'ing some maintainers. I expect this will also explode when a CPU is runtime offlined with `xen-hptool cpu-offline` and then added to a cpupool. Interestingly, the crash is mov (%rdx,%rax,1),%r13, and I think that's the percpu posion value in %rdx. I expect cpupools want to reject parked/offline CPUs. While the only explicit check there is if ( cpu >= nr_cpu_ids ) goto addcpu_out; I would have expected this if ( !cpumask_subset(cpus, _free_cpus) || cpumask_intersects(cpus, _locked_cpus) ) goto addcpu_out; to deal with the situation, as parked/offline CPUs shouldn't be "free". Jürgen? The problem is the call of sched_get_opt_cpumask() to need the percpu area of the cpu in question. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Trying add smt=off disabled cores to cpupool crash xen
On 01.12.2023 21:12, Andrew Cooper wrote: > On 01/12/2023 7:59 pm, René Winther Højgaard wrote: >> If I set smt=off and try to configure cpupools with credit(1) as if >> all cores are available, I get the following crash. >> >> The crash happens when I try to use xl cpupool-add-cpu on the disabled >> HT sibling cores. >> >> Hyper-threading is enabled in the firmware, and only disabled with >> smt=off. > > CC'ing some maintainers. > > I expect this will also explode when a CPU is runtime offlined with > `xen-hptool cpu-offline` and then added to a cpupool. > > Interestingly, the crash is mov (%rdx,%rax,1),%r13, and I think that's > the percpu posion value in %rdx. > > I expect cpupools want to reject parked/offline CPUs. While the only explicit check there is if ( cpu >= nr_cpu_ids ) goto addcpu_out; I would have expected this if ( !cpumask_subset(cpus, _free_cpus) || cpumask_intersects(cpus, _locked_cpus) ) goto addcpu_out; to deal with the situation, as parked/offline CPUs shouldn't be "free". Jürgen? Jan
Re: Trying add smt=off disabled cores to cpupool crash xen
On 01.12.23 21:12, Andrew Cooper wrote:
On 01/12/2023 7:59 pm, René Winther Højgaard wrote:
If I set smt=off and try to configure cpupools with credit(1) as if
all cores are available, I get the following crash.
The crash happens when I try to use xl cpupool-add-cpu on the disabled
HT sibling cores.
Hyper-threading is enabled in the firmware, and only disabled with
smt=off.
CC'ing some maintainers.
Attached patch should fix the crash.
René, are you fine with the "Reported-by:" tag being added to the patch?
I'll send a proper patch mail when having heard from you.
Juergen
From 65c70cc53df3a71225b11cb95848f12f5a565d5d Mon Sep 17 00:00:00 2001
From: Juergen Gross
Date: Mon, 4 Dec 2023 08:00:21 +0100
Subject: [PATCH] xen/sched: fix adding offline cpu to cpupool
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Trying to add an offline cpu to a cpupool can crash the hypervisor,
as the probably non-existing percpu area of the cpu is accessed before
the availability of the cpu is being tested.
Fix that by testing the cpu to be online.
Fixes: cb563d7665f2 ("xen/sched: support core scheduling for moving cpus to/from cpupools")
Reported-by: René Winther Højgaard
Signed-off-by: Juergen Gross
---
xen/common/sched/cpupool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 2e094b0cfa..ad8f608462 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -892,6 +892,8 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
if ( cpu >= nr_cpu_ids )
goto addcpu_out;
ret = -ENODEV;
+if ( !cpu_online(cpu) )
+goto addcpu_out;
cpus = sched_get_opt_cpumask(c->gran, cpu);
if ( !cpumask_subset(cpus, _free_cpus) ||
cpumask_intersects(cpus, _locked_cpus) )
--
2.35.3
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Trying add smt=off disabled cores to cpupool crash xen
On 01/12/2023 7:59 pm, René Winther Højgaard wrote: > If I set smt=off and try to configure cpupools with credit(1) as if > all cores are available, I get the following crash. > > The crash happens when I try to use xl cpupool-add-cpu on the disabled > HT sibling cores. > > Hyper-threading is enabled in the firmware, and only disabled with > smt=off. CC'ing some maintainers. I expect this will also explode when a CPU is runtime offlined with `xen-hptool cpu-offline` and then added to a cpupool. Interestingly, the crash is mov (%rdx,%rax,1),%r13, and I think that's the percpu posion value in %rdx. I expect cpupools want to reject parked/offline CPUs. ~Andrew > > Software: Xen-4.17.3 / Qubes OS 4.2.0-RC5 > Firmware: Dasharo 0.9.0 - Z790P > Hardware: 13900K > > (XEN) [ Xen-4.17.3-pre x86_64 debug=y Not tainted ] > (XEN) CPU: 6 > (XEN) RIP: e008:[] schedule_cpu_add+0x50/0x456 > (XEN) RFLAGS: 00010202 CONTEXT: hypervisor (d0v3) > (XEN) rax: 82d0405a9288 rbx: 83107f5a1980 rcx: > 0020 > (XEN) rdx: 80007d2fbfa59000 rsi: 83107f5a1980 rdi: > 0020 > (XEN) rbp: 0009 rsp: 831087d3fc68 r8: > > (XEN) r9: 82d0405b6b60 r10: 831087d22ab0 r11: > 0003 > (XEN) r12: 831087d22ab0 r13: 0020 r14: > 831087d22ab0 > (XEN) r15: 82d0405ae680 cr0: 80050033 cr4: > 00b526e0 > (XEN) cr3: 000912e3 cr2: 72e5cb008375 > (XEN) fsb: 72e5caac7380 gsb: 8881b9d8 gss: > > (XEN) ds: es: fs: gs: ss: e010 cs: e008 > (XEN) Xen code around (schedule_cpu_add+0x50/0x456): > (XEN) db 8e 37 00 48 8b 14 ca <4c> 8b 2c 02 3b 3d 75 f0 1f 00 0f 83 > c9 01 00 00 > (XEN) Xen stack trace from rsp=831087d3fc68: > (XEN) 83107f5a16e0 82d040204c3b 83100018 > 831087d3fd28 > (XEN) 831087d3fcc8 3431831087d3fcd0 83107f002033 > 831087d3fcd0 > (XEN) 831087d40d70 82d040246d48 > > (XEN) 83107f5a1980 0009 831087d22ab0 > 0020 > (XEN) 831087d22ab0 82d0405ae680 82d040235dec > 831087d3fe20 > (XEN) ffed 0009 83107f5a1980 > 82d040236b05 > (XEN) 72e5cb098010 > 831087d3 > (XEN) 82d04045d5d8 82d040234763 > c102 > (XEN) c102 > 000d > (XEN) 8101ede6 e033 00011082 > c90043c1fb00 > (XEN) e02b 11e6f31d9b4cbeef 96994088d9fcbeef > 7d897394f3ecbeef > (XEN) c501dd1632b4beef 82d040227cc6 831087d3fe48 > > (XEN) 00011082 831087d3 > > (XEN) 8101ede4 82d0403495d0 00150012 > 00020004 > (XEN) 0009 72e5cad9cb60 > 7be382ddb0c16b00 > (XEN) 00a97768 00a97150 > 7ffe90589abc > (XEN) 7ffe9058a780 0043d990 0043d9b0 > 72e5cad20434 > (XEN) 7ffe90589ac0 72e5cafa3f79 0008 > 831087d3fef8 > (XEN) 0023 83107f52b000 > > (XEN) 82d0402dd07f 83107f52b000 > > (XEN) Xen call trace: > (XEN) [] R schedule_cpu_add+0x50/0x456 > (XEN) [] S debugtrace_printk+0x119/0x2cc > (XEN) [] S free_affinity_masks+0x15/0x17 > (XEN) [] S > cpupool.c#cpupool_assign_cpu_locked+0x53/0x160 > (XEN) [] S cpupool_do_sysctl+0x367/0x760 > (XEN) [] S do_sysctl+0x827/0x1269 > (XEN) [] S timer.c#timer_lock+0x69/0x143 > (XEN) [] S x86_emulate_wrapper+0x24/0x56 > (XEN) [] S pv_hypercall+0x3a2/0x4a9 > (XEN) [] S lstar_enter+0x137/0x140 > (XEN) > (XEN) debugtrace_dump() global buffer starting > (XEN) wrap: 0 > (XEN) debugtrace_dump() global buffer finished > (XEN) > (XEN) > (XEN) Panic on CPU 6: > (XEN) GENERAL PROTECTION FAULT > (XEN) [error_code=] > (XEN) > (XEN) > (XEN) Reboot in five seconds... > > /rene
Trying add smt=off disabled cores to cpupool crash xen
If I set smt=off and try to configure cpupools with credit(1) as if all cores are available, I get the following crash. The crash happens when I try to use xl cpupool-add-cpu on the disabled HT sibling cores. Hyper-threading is enabled in the firmware, and only disabled with smt=off. Software: Xen-4.17.3 / Qubes OS 4.2.0-RC5 Firmware: Dasharo 0.9.0 - Z790P Hardware: 13900K (XEN) [ Xen-4.17.3-pre x86_64 debug=y Not tainted ](XEN) CPU: 6 (XEN) RIP: e008:[] schedule_cpu_add+0x50/0x456 (XEN) RFLAGS: 00010202 CONTEXT: hypervisor (d0v3) (XEN) rax: 82d0405a9288 rbx: 83107f5a1980 rcx: 0020 (XEN) rdx: 80007d2fbfa59000 rsi: 83107f5a1980 rdi: 0020 (XEN) rbp: 0009 rsp: 831087d3fc68 r8: (XEN) r9: 82d0405b6b60 r10: 831087d22ab0 r11: 0003 (XEN) r12: 831087d22ab0 r13: 0020 r14: 831087d22ab0 (XEN) r15: 82d0405ae680 cr0: 80050033 cr4: 00b526e0 (XEN) cr3: 000912e3 cr2: 72e5cb008375 (XEN) fsb: 72e5caac7380 gsb: 8881b9d8 gss: (XEN) ds: es: fs: gs: ss: e010 cs: e008 (XEN) Xen code around (schedule_cpu_add+0x50/0x456): (XEN) db 8e 37 00 48 8b 14 ca <4c> 8b 2c 02 3b 3d 75 f0 1f 00 0f 83 c9 01 00 00 (XEN) Xen stack trace from rsp=831087d3fc68: (XEN) 83107f5a16e0 82d040204c3b 83100018 831087d3fd28 (XEN) 831087d3fcc8 3431831087d3fcd0 83107f002033 831087d3fcd0 (XEN) 831087d40d70 82d040246d48 (XEN) 83107f5a1980 0009 831087d22ab0 0020 (XEN) 831087d22ab0 82d0405ae680 82d040235dec 831087d3fe20 (XEN) ffed 0009 83107f5a1980 82d040236b05 (XEN) 72e5cb098010 831087d3 (XEN) 82d04045d5d8 82d040234763 c102 (XEN) c102 000d (XEN) 8101ede6 e033 00011082 c90043c1fb00 (XEN) e02b 11e6f31d9b4cbeef 96994088d9fcbeef 7d897394f3ecbeef (XEN) c501dd1632b4beef 82d040227cc6 831087d3fe48 (XEN) 00011082 831087d3 (XEN) 8101ede4 82d0403495d0 00150012 00020004 (XEN) 0009 72e5cad9cb60 7be382ddb0c16b00 (XEN) 00a97768 00a97150 7ffe90589abc (XEN) 7ffe9058a780 0043d990 0043d9b0 72e5cad20434 (XEN) 7ffe90589ac0 72e5cafa3f79 0008 831087d3fef8 (XEN) 0023 83107f52b000 (XEN) 82d0402dd07f 83107f52b000 (XEN) Xen call trace: (XEN) [] R schedule_cpu_add+0x50/0x456 (XEN) [] S debugtrace_printk+0x119/0x2cc (XEN) [] S free_affinity_masks+0x15/0x17 (XEN) [] S cpupool.c#cpupool_assign_cpu_locked+0x53/0x160 (XEN) [] S cpupool_do_sysctl+0x367/0x760 (XEN) [] S do_sysctl+0x827/0x1269 (XEN) [] S timer.c#timer_lock+0x69/0x143 (XEN) [] S x86_emulate_wrapper+0x24/0x56 (XEN) [] S pv_hypercall+0x3a2/0x4a9 (XEN) [] S lstar_enter+0x137/0x140 (XEN) (XEN) debugtrace_dump() global buffer starting (XEN) wrap: 0 (XEN) debugtrace_dump() global buffer finished (XEN) (XEN) (XEN) Panic on CPU 6: (XEN) GENERAL PROTECTION FAULT (XEN) [error_code=] (XEN) (XEN) (XEN) Reboot in five seconds... /rene publickey - renewin@proton.me - 0x43C32E54.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
