Re: [PATCH v2 0/2] PCI/AER: Report fatal errors of RCiEP and EP if link recoverd
在 2024/11/12 21:54, Shuai Xue 写道: changes since v1: - rewrite commit log per Bjorn - refactor aer_get_device_error_info to reduce duplication per Keith - fix to avoid reporting fatal errors twice for root and downstream ports per Keith The AER driver has historically avoided reading the configuration space of an endpoint or RCiEP that reported a fatal error, considering the link to that device unreliable. Consequently, when a fatal error occurs, the AER and DPC drivers do not report specific error types, resulting in logs like: pcieport :30:03.0: EDR: EDR event received pcieport :30:03.0: DPC: containment event, status:0x0005 source:0x3400 pcieport :30:03.0: DPC: ERR_FATAL detected pcieport :30:03.0: AER: broadcast error_detected message nvme nvme0: frozen state error detected, reset controller nvme :34:00.0: ready 0ms after DPC pcieport :30:03.0: AER: broadcast slot_reset message AER status registers are sticky and Write-1-to-clear. If the link recovered after hot reset, we can still safely access AER status of the error device. In such case, report fatal errors which helps to figure out the error root case. - Patch 1/2 identifies the error device by SOURCE ID register - Patch 2/3 reports the AER status if link recoverd. After this patch set, the logs like: pcieport :30:03.0: EDR: EDR event received pcieport :30:03.0: DPC: containment event, status:0x0005 source:0x3400 pcieport :30:03.0: DPC: ERR_FATAL detected pcieport :30:03.0: AER: broadcast error_detected message nvme nvme0: frozen state error detected, reset controller pcieport :30:03.0: waiting 100 ms for downstream link, after activation nvme :34:00.0: ready 0ms after DPC nvme :34:00.0: PCIe Bus Error: severity=Uncorrectable (Fatal), type=Data Link Layer, (Receiver ID) nvme :34:00.0: device [144d:a804] error status/mask=0010/00504000 nvme :34:00.0:[ 4] DLP(First) pcieport :30:03.0: AER: broadcast slot_reset message Shuai Xue (2): PCI/DPC: Run recovery on device that detected the error PCI/AER: Report fatal errors of RCiEP and EP if link recoverd drivers/pci/pci.h | 5 +++-- drivers/pci/pcie/aer.c | 11 +++ drivers/pci/pcie/dpc.c | 32 +--- drivers/pci/pcie/edr.c | 35 ++- drivers/pci/pcie/err.c | 9 + 5 files changed, 62 insertions(+), 30 deletions(-) Hi, all, Gentle ping. Best Regards, Shuai
KVM: PPC: Book3E: KVM HV host module doesn't work anymore
On 23/12/24 16:37, Paolo Bonzini wrote:
On Mon, Dec 23, 2024 at 3:41 PM Christian Zigotzky
wrote:
Bisecting: a merge base must be tested
[e9001a382fa2c256229adc68d55212028b01d515] Merge tag
'kvmarm-fixes-6.12-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
The host system doesn't boot.
Unfortunately, there isn't a guest kernel boot log via serial log.
No big deal since the boot hang was fixed via rebase.
git checkout -b bisection-rebase
b467ab82a9fde4b46c0cd2c299220857afb0e0d4
git rebase v6.12
The host kernel boots but the guest kernel doesn't boot so KVM HV
doesn't work.
As expected, so that's good.
git bisect start
git bisect bad bisection-rebase
git bisect good v6.12
[skipping bisection process]
`edebc0a1b7ab5ff19b4f5cd011c93196fc34b3e4 is the first bad commit
Ok, that means that the culprit is commit 419cfb983ca93 (the above
is the rebased hash). Thank you very much, your work was really
helpful!
Can you test this simple patch?
--- 8<
From: Paolo Bonzini
Subject: [PATCH] KVM: allow NULL writable argument to __kvm_faultin_pfn
kvm_follow_pfn() is able to work with NULL in the .map_writable field
of the homonymous struct. But __kvm_faultin_pfn() rejects the combo
despite KVM for e500 trying to use it. Indeed .map_writable is not
particularly useful if the flags include FOLL_WRITE and readonly
guest memory is not supported, so add support to __kvm_faultin_pfn()
for this case.
Fixes: 1c7b627e9306 ("KVM: Add kvm_faultin_pfn() to specifically
service guest page faults")
Signed-off-by: Paolo Bonzini
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index de2c11dae231..5177e56fdbd5 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2975,10 +2975,11 @@ kvm_pfn_t __kvm_faultin_pfn(const struct
kvm_memory_slot *slot, gfn_t gfn,
.refcounted_page = refcounted_page,
};
- if (WARN_ON_ONCE(!writable || !refcounted_page))
+ if (WARN_ON_ONCE(!refcounted_page))
return KVM_PFN_ERR_FAULT;
- *writable = false;
+ if (writable)
+ *writable = false;
*refcounted_page = NULL;
return kvm_follow_pfn(&kfp);
Thanks,
Paolo
Hello Paolo,
Thanks a lot for your patch.
I tested it with the RC4 of kernel 6.13 today but unfortunately it
doesn't solve the KVM HV issue. The guest system doesn't boot and I
can't see any error messages. (console=ttyS0)
Regards,
Christian
--
Sent with BrassMonkey 33.4.0
(https://github.com/wicknix/brass-monkey/releases/tag/33.4.0)
[PATCH] net: ethernet: toshiba: ps3_gelic_wireless: Remove driver using deprecated API wext
Driver was contributed in 2008.
The following reasons lead to the removal:
- This driver generates maintenance workload for itself and for API wext
- wext is deprecated and only used by two wireless drivers in
mainline kernel
- no progress changing to mac80211
- This driver has a maximum 54MBit/s as it supports only 802.11 b/g.
- Using this hardware is security wise not state of the art as WPA3 is
not supported.
The longterm kernels will still support this hardware for years.
Find further discussions and history in the Link below.
Link:
https://lore.kernel.org/linux-staging/a7eb3db4-ad0d-451a-9106-90d481bd3...@gmail.com/
Signed-off-by: Philipp Hortmann
---
Only compile tested.
Tested a rebased version of this patch on the Playstation 3. Used
T2 Linux with Kernel 6.12.5 to test the Ethernet connection.
No updates required in MAINTAINERS.
---
drivers/net/ethernet/toshiba/Kconfig | 11 -
drivers/net/ethernet/toshiba/Makefile |3 +-
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 17 -
.../net/ethernet/toshiba/ps3_gelic_wireless.c | 2654 -
.../net/ethernet/toshiba/ps3_gelic_wireless.h | 313 --
5 files changed, 1 insertion(+), 2997 deletions(-)
delete mode 100644 drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
delete mode 100644 drivers/net/ethernet/toshiba/ps3_gelic_wireless.h
diff --git a/drivers/net/ethernet/toshiba/Kconfig
b/drivers/net/ethernet/toshiba/Kconfig
index 701e9b7c1c3b..039ad7558c0f 100644
--- a/drivers/net/ethernet/toshiba/Kconfig
+++ b/drivers/net/ethernet/toshiba/Kconfig
@@ -28,17 +28,6 @@ config GELIC_NET
To compile this driver as a module, choose M here: the
module will be called ps3_gelic.
-config GELIC_WIRELESS
- bool "PS3 Wireless support"
- depends on GELIC_NET && WLAN
- select WIRELESS_EXT
- help
- This option adds the support for the wireless feature of PS3.
- If you have the wireless-less model of PS3 or have no plan to
- use wireless feature, disabling this option saves memory. As
- the driver automatically distinguishes the models, you can
- safely enable this option even if you have a wireless-less model.
-
config SPIDER_NET
tristate "Spider Gigabit Ethernet driver"
depends on PCI && PPC_IBM_CELL_BLADE
diff --git a/drivers/net/ethernet/toshiba/Makefile
b/drivers/net/ethernet/toshiba/Makefile
index f434fd0f429e..f5c4a7c22679 100644
--- a/drivers/net/ethernet/toshiba/Makefile
+++ b/drivers/net/ethernet/toshiba/Makefile
@@ -4,8 +4,7 @@
#
obj-$(CONFIG_GELIC_NET) += ps3_gelic.o
-gelic_wireless-$(CONFIG_GELIC_WIRELESS) += ps3_gelic_wireless.o
-ps3_gelic-objs += ps3_gelic_net.o $(gelic_wireless-y)
+ps3_gelic-objs += ps3_gelic_net.o
spidernet-y += spider_net.o spider_net_ethtool.o
obj-$(CONFIG_SPIDER_NET) += spidernet.o
obj-$(CONFIG_TC35815) += tc35815.o
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index 5ee8e8980393..2f248e62cb74 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -35,7 +35,6 @@
#include
#include "ps3_gelic_net.h"
-#include "ps3_gelic_wireless.h"
#define DRV_NAME "Gelic Network Driver"
#define DRV_VERSION "2.0"
@@ -1148,12 +1147,6 @@ static irqreturn_t gelic_card_interrupt(int irq, void
*ptr)
if (status & GELIC_CARD_PORT_STATUS_CHANGED)
gelic_card_get_ether_port_status(card, 1);
-#ifdef CONFIG_GELIC_WIRELESS
- if (status & (GELIC_CARD_WLAN_EVENT_RECEIVED |
- GELIC_CARD_WLAN_COMMAND_COMPLETED))
- gelic_wl_interrupt(card->netdev[GELIC_PORT_WIRELESS], status);
-#endif
-
return IRQ_HANDLED;
}
@@ -1769,13 +1762,6 @@ static int ps3_gelic_driver_probe(struct
ps3_system_bus_device *dev)
goto fail_setup_netdev;
}
-#ifdef CONFIG_GELIC_WIRELESS
- result = gelic_wl_driver_probe(card);
- if (result) {
- dev_dbg(&dev->core, "%s: WL init failed\n", __func__);
- goto fail_setup_netdev;
- }
-#endif
pr_debug("%s: done\n", __func__);
return 0;
@@ -1818,9 +1804,6 @@ static void ps3_gelic_driver_remove(struct
ps3_system_bus_device *dev)
/* set auto-negotiation */
gelic_card_set_link_mode(card, GELIC_LV1_ETHER_AUTO_NEG);
-#ifdef CONFIG_GELIC_WIRELESS
- gelic_wl_driver_remove(card);
-#endif
/* stop interrupt */
gelic_card_set_irq_mask(card, 0);
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
deleted file mode 100644
index 4fbe4b7cd12a..
--- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
+++ /dev/null
@@ -1,2654 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * PS3 gelic network driver.
- *
- * Copyright (C) 2007 Sony Computer Entertainment Inc.
- * Copyright 2007 Sony Corporation
- */
-#undef DE
Re: KVM: PPC: Book3E: KVM HV host module doesn't work anymore
On 12/24/24 12:05, Christian Zigotzky wrote: Hello Paolo, Thanks a lot for your patch. I tested it with the RC4 of kernel 6.13 today but unfortunately it doesn't solve the KVM HV issue. The guest system doesn't boot and I can't see any error messages. (console=ttyS0) But do you see anything on the host dmesg (without and with the patch), for example a WARN? Also you might try edebc0a1b7ab5ff19b4f5cd011c93196fc34b3e4 + the patch, to see if there are two bugs. Paolo
Re: [PATCH v10 1/4] cpu/SMT: Provide a default topology_is_primary_thread()
On 2024/12/24 0:34, Jonathan Cameron wrote:
> On Fri, 20 Dec 2024 15:59:27 +0800
> Yicong Yang wrote:
>
>> On 2024/12/20 15:53, Yicong Yang wrote:
>>> From: Yicong Yang
>>>
>>> Currently if architectures want to support HOTPLUG_SMT they need to
>>> provide a topology_is_primary_thread() telling the framework which
>>> thread in the SMT cannot offline. However arm64 doesn't have a
>>> restriction on which thread in the SMT cannot offline, a simplest
>>> choice is that just make 1st thread as the "primary" thread. So
>>> just make this as the default implementation in the framework and
>>> let architectures like x86 that have special primary thread to
>>> override this function (which they've already done).
>>>
>>> There's no need to provide a stub function if !CONFIG_SMP or
>>> !CONFIG_HOTPLUG_SMP. In such case the testing CPU is already
>>> the 1st CPU in the SMT so it's always the primary thread.
>>>
>>> Signed-off-by: Yicong Yang
>>> ---
>>> As questioned in v9 [1] whether this works on architectures not using
>>> CONFIG_GENERIC_ARCH_TOPOLOGY, hacked on LoongArch VM and this also works.
>>> Architectures should use this on their own situation.
>>> [1]
>>> https://lore.kernel.org/linux-arm-kernel/427bd639-33c3-47e4-9e83-68c428eb1...@arm.com/
>>>
>>> [root@localhost smt]# uname -m
>>> loongarch64
>>> [root@localhost smt]# pwd
>>> /sys/devices/system/cpu/smt
>>> [root@localhost smt]# cat ../possible
>>> 0-3
>>> [root@localhost smt]# cat ../online
>>> 0-3
>>> [root@localhost smt]# cat control
>>> on
>>> [root@localhost smt]# echo off > control
>>> [root@localhost smt]# cat control
>>> off
>>> [root@localhost smt]# cat ../online
>>> 0,2
>>> [root@localhost smt]# echo on > control
>>> [root@localhost smt]# cat control
>>> on
>>> [root@localhost smt]# cat ../online
>>> 0-3
>>
>> Tested with below code using the topology_is_primary_thread() introduced
>> in this patch. Tested on an ACPI-based QEMU VM emulating SMT2.
> Nice bit of testing.
>
> Given it all seems fine. FWIW
> Reviewed-by: Jonathan Cameron
> (for original patch, not the longarch one!)
thanks. certainly :)
>
>>
>> Subject: [PATCH] LoongArch: Support HOTPLUG_SMT on ACPI-based system
>>
>> Support HOTPLUG_SMT on ACPI-based system using generic
>> topology_is_primary_thread().
>>
>> Signed-off-by: Yicong Yang
>> ---
>> arch/loongarch/Kconfig | 1 +
>> arch/loongarch/kernel/acpi.c | 26 --
>> 2 files changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
>> index dae3a9104ca6..bed1b0640b97 100644
>> --- a/arch/loongarch/Kconfig
>> +++ b/arch/loongarch/Kconfig
>> @@ -172,6 +172,7 @@ config LOONGARCH
>> select HAVE_SYSCALL_TRACEPOINTS
>> select HAVE_TIF_NOHZ
>> select HAVE_VIRT_CPU_ACCOUNTING_GEN if !SMP
>> +select HOTPLUG_SMT if HOTPLUG_CPU
>> select IRQ_FORCED_THREADING
>> select IRQ_LOONGARCH_CPU
>> select LOCK_MM_AND_FIND_VMA
>> diff --git a/arch/loongarch/kernel/acpi.c b/arch/loongarch/kernel/acpi.c
>> index 382a09a7152c..e642b0de57e7 100644
>> --- a/arch/loongarch/kernel/acpi.c
>> +++ b/arch/loongarch/kernel/acpi.c
>> @@ -15,9 +15,11 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> +#include
>>
>> int acpi_disabled;
>> EXPORT_SYMBOL(acpi_disabled);
>> @@ -175,8 +177,12 @@ int pptt_enabled;
>>
>> int __init parse_acpi_topology(void)
>> {
>> +int thread_num, max_smt_thread_num = 1;
>> +struct xarray core_threads;
>> int cpu, topology_id;
>> +void *entry;
>>
>> +xa_init(&core_threads);
>> for_each_possible_cpu(cpu) {
>> topology_id = find_acpi_cpu_topology(cpu, 0);
>> if (topology_id < 0) {
>> @@ -184,19 +190,35 @@ int __init parse_acpi_topology(void)
>> return -ENOENT;
>> }
>>
>> -if (acpi_pptt_cpu_is_thread(cpu) <= 0)
>> +if (acpi_pptt_cpu_is_thread(cpu) <= 0) {
>> cpu_data[cpu].core = topology_id;
>> -else {
>> +} else {
>> topology_id = find_acpi_cpu_topology(cpu, 1);
>> if (topology_id < 0)
>> return -ENOENT;
>>
>> cpu_data[cpu].core = topology_id;
>> +
>> +entry = xa_load(&core_threads, topology_id);
>> +if (!entry) {
>> +xa_store(&core_threads, topology_id,
>> + xa_mk_value(1), GFP_KERNEL);
>> +} else {
>> +thread_num = xa_to_value(entry);
>> +thread_num++;
>> +xa_store(&core_threads, topology_id,
>> + xa_mk_value(thread_num), GFP_KERNEL);
>> +
>> +if (thread_num > max_smt_thread_num)
>> +max_smt_thread
Re: [PATCH v10 2/4] arch_topology: Support SMT control for OF based system
On 2024/12/24 0:33, Jonathan Cameron wrote:
> On Fri, 20 Dec 2024 15:53:11 +0800
> Yicong Yang wrote:
>
>> From: Yicong Yang
>>
>> On building the topology from the devicetree, we've already
>> gotten the SMT thread number of each core. Update the largest
>> SMT thread number and enable the SMT control by the end of
>> topology parsing.
>>
>> The core's SMT control provides two interface to the users [1]:
>> 1) enable/disable SMT by writing on/off
>> 2) enable/disable SMT by writing thread number 1/max_thread_number
>>
>> If a system have more than one SMT thread number the 2) may
>> not handle it well, since there're multiple thread numbers in the
>> system and 2) only accept 1/max_thread_number. So issue a warning
>> to notify the users if such system detected.
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-devices-system-cpu#n542
>> Signed-off-by: Yicong Yang
> Hi Yicong,
>
> Apologies that I'm late to the game on this one.
>
> A few comments inline. Only important one is whether to bail out early
> on error from parse_cluster()
>
thanks for the comments.
> Thanks,
>
> Jonathan
>
>
>> ---
>> drivers/base/arch_topology.c | 26 ++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
>> index 3ebe77566788..9e81060144c7 100644
>> --- a/drivers/base/arch_topology.c
>> +++ b/drivers/base/arch_topology.c
>> @@ -11,6 +11,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -506,6 +507,10 @@ core_initcall(free_raw_capacity);
>> #endif
>>
>> #if defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
>> +
>> +/* Maximum SMT thread number detected used to enable the SMT control */
>> +static unsigned int max_smt_thread_num;
>> +
>> /*
>> * This function returns the logic cpu number of the node.
>> * There are basically three kinds of return values:
>> @@ -565,6 +570,17 @@ static int __init parse_core(struct device_node *core,
>> int package_id,
>> i++;
>> } while (1);
>>
>> +/*
>> + * If max_smt_thread_num has been initialized and doesn't match
>> + * the thread number of this entry, then the system has
>> + * heterogeneous SMT topology.
>> + */
>> +if (max_smt_thread_num && max_smt_thread_num != i)
>> +pr_warn_once("Heterogeneous SMT topology is partly supported by
>> SMT control\n");
>> +
>> +if (max_smt_thread_num < i)
>> +max_smt_thread_num = i;
>
> Maybe more self documenting if you use min()? I'm not sure...
> max_smt_thread_num = min(max_smt_thread_num, i);
>
sure, will use max_t here (since we'd like to know the maximum thread number).
>
>> +
>> cpu = get_cpu_for_node(core);
>> if (cpu >= 0) {
>> if (!leaf) {
>> @@ -677,6 +693,16 @@ static int __init parse_socket(struct device_node
>> *socket)
>> if (!has_socket)
>> ret = parse_cluster(socket, 0, -1, 0);
>
> Is it appropriate to check ret before setting num threads?
> if (!has_socket) {
> ret = parse_cluster(socket, 0, -1, 0);
> if (ret)
> return ret;
> }
> ...
>
> return 0;
>
thanks for catching this. since we always need to notify the framework of
the SMT thread number if HOTPLUG_SMT selected, we should make it to 1 if
topology parsing failed. Since on failure the topology information will
be reset, a thread_number of 1 will be handled as SMT not supported.
>>
>> +/*
>> + * Notify the CPU framework of the SMT support. Initialize the
>> + * max_smt_thread_num to 1 if no SMT support detected. A thread
>> + * number of 1 can be handled by the framework so we don't need
>> + * to check max_smt_thread_num to see we support SMT or not.
>> + */
>> +if (!max_smt_thread_num)
>> +max_smt_thread_num = 1;
>> +
>> +cpu_smt_set_num_threads(max_smt_thread_num, max_smt_thread_num);
>
> Trivial but I'd put a blank line here.
>
ok.
Thanks.
Re: [PATCH v10 3/4] arm64: topology: Support SMT control on ACPI based system
On 2024/12/24 0:40, Jonathan Cameron wrote:
> On Fri, 20 Dec 2024 15:53:12 +0800
> Yicong Yang wrote:
>
>> From: Yicong Yang
>>
>> For ACPI we'll build the topology from PPTT and we cannot directly
>> get the SMT number of each core. Instead using a temporary xarray
>> to record the heterogeneous information (from ACPI_PPTT_ACPI_IDENTICAL)
>> and SMT information of the first core in its heterogeneous CPU cluster
>> when building the topology. Then we can know the largest SMT number
>> in the system. If a homogeneous system's using ACPI 6.2 or later,
>> all the CPUs should be under the root node of PPTT. There'll be
>> only one entry in the xarray and all the CPUs in the system will
>> be assumed identical.
>>
>> The core's SMT control provides two interface to the users [1]:
>> 1) enable/disable SMT by writing on/off
>> 2) enable/disable SMT by writing thread number 1/max_thread_number
>>
>> If a system have more than one SMT thread number the 2) may
>> not handle it well, since there're multiple thread numbers in the
>> system and 2) only accept 1/max_thread_number. So issue a warning
>> to notify the users if such system detected.
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-devices-system-cpu#n542
>> Signed-off-by: Yicong Yang
>
> A few trivial things inline. Either way it's fine as really just my style
> preferences
>
> Reviewed-by: Jonathan Cameron
>
>> ---
>> arch/arm64/kernel/topology.c | 66
>> 1 file changed, 66 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>> index 1a2c72f3e7f8..85cb18d72a29 100644
>> --- a/arch/arm64/kernel/topology.c
>> +++ b/arch/arm64/kernel/topology.c
>> @@ -15,8 +15,10 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -37,17 +39,28 @@ static bool __init acpi_cpu_is_threaded(int cpu)
>> return !!is_threaded;
>> }
>>
>> +struct cpu_smt_info {
>> +int thread_num;
>> +int core_id;
>> +};
>> +
>> /*
>> * Propagate the topology information of the processor_topology_node tree
>> to the
>> * cpu_topology array.
>> */
>> int __init parse_acpi_topology(void)
>> {
>> +int max_smt_thread_num = 0;
>> +struct cpu_smt_info *entry;
>> +struct xarray hetero_cpu;
>> +unsigned long hetero_id;
>> int cpu, topology_id;
>>
>> if (acpi_disabled)
>> return 0;
>>
>> +xa_init(&hetero_cpu);
>> +
>> for_each_possible_cpu(cpu) {
>> topology_id = find_acpi_cpu_topology(cpu, 0);
>> if (topology_id < 0)
>> @@ -57,6 +70,32 @@ int __init parse_acpi_topology(void)
>> cpu_topology[cpu].thread_id = topology_id;
>> topology_id = find_acpi_cpu_topology(cpu, 1);
>> cpu_topology[cpu].core_id = topology_id;
>> +
>> +/*
>> + * In the PPTT, CPUs below a node with the 'identical
>> + * implementation' flag have the same number of threads.
>> + * Count the number of threads for only one CPU (i.e.
>> + * one core_id) among those with the same hetero_id.
>> + * See the comment of find_acpi_cpu_topology_hetero_id()
>> + * for more details.
>> + *
>> + * One entry is created for each node having:
>> + * - the 'identical implementation' flag
>> + * - its parent not having the flag
>> + */
>> +hetero_id = find_acpi_cpu_topology_hetero_id(cpu);
>> +entry = (struct cpu_smt_info *)xa_load(&hetero_cpu,
>> hetero_id);
>
> Given xa_load returns a void *,
>
> entry = xa_load(&hetero_cpu, hetero_id);
>
> should be fine (I haven't checked local style, so feel free to ignore if
> local style is to cast anyway). Maybe drag the definition of entry into
> a more local scope as well.
>
sure. will get rid of the cast and checked it won't violate the local style.
>
>> +if (!entry) {
>> +entry = kzalloc(sizeof(*entry), GFP_KERNEL);
>> +WARN_ON(!entry);
>> +
>> +entry->core_id = topology_id;
>> +entry->thread_num = 1;
>> +xa_store(&hetero_cpu, hetero_id,
>> + entry, GFP_KERNEL);
>> +} else if (entry->core_id == topology_id) {
>> +entry->thread_num++;
>> +}
>> } else {
>> cpu_topology[cpu].thread_id = -1;
>> cpu_topology[cpu].core_id= topology_id;
>> @@ -67,6 +106,33 @@ int __init parse_acpi_topology(vo
Re: [PATCH] powerpc/pseries/vas: Add close() callback in vas_vm_ops struct
On Fri, 13 Dec 2024 21:17:58 -0800, Haren Myneni wrote: > The mapping VMA address is saved in VAS window struct when the > paste address is mapped. This VMA address is used during migration > to unmap the paste address if the window is active. The paste > address mapping will be removed when the window is closed or with > the munmap(). But the VMA address in the VAS window is not updated > with munmap() which is causing invalid access during migration. > > [...] Applied to powerpc/fixes. [1/1] powerpc/pseries/vas: Add close() callback in vas_vm_ops struct https://git.kernel.org/powerpc/c/05aa156e156ef3168e7ab8a68721945196495c17 Thanks
