[linux-next PATCH] mm/gup.c: Convert to use get_user_{page|pages}_fast_only()
API __get_user_pages_fast() renamed to get_user_pages_fast_only()
to align with pin_user_pages_fast_only().
As part of this we will get rid of write parameter.
Instead caller will pass FOLL_WRITE to get_user_pages_fast_only().
This will not change any existing functionality of the API.
All the callers are changed to pass FOLL_WRITE.
Also introduce get_user_page_fast_only(), and use it in a few
places that hard-code nr_pages to 1.
Updated the documentation of the API.
Signed-off-by: Souptick Joarder
Reviewed-by: John Hubbard
Cc: Matthew Wilcox
Cc: John Hubbard
---
arch/powerpc/kvm/book3s_64_mmu_hv.c| 2 +-
arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
arch/powerpc/perf/callchain_64.c | 4 +---
include/linux/mm.h | 10 --
kernel/events/core.c | 4 ++--
mm/gup.c | 29 -
virt/kvm/kvm_main.c| 8 +++-
7 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 18aed97..ddfc4c9 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -581,7 +581,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct
kvm_vcpu *vcpu,
* We always ask for write permission since the common case
* is that the page is writable.
*/
- if (__get_user_pages_fast(hva, 1, 1, &page) == 1) {
+ if (get_user_page_fast_only(hva, FOLL_WRITE, &page)) {
write_ok = true;
} else {
/* Call KVM generic code to do the slow-path check */
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c
b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index 3248f78..5d4c087 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -795,7 +795,7 @@ int kvmppc_book3s_instantiate_page(struct kvm_vcpu *vcpu,
* is that the page is writable.
*/
hva = gfn_to_hva_memslot(memslot, gfn);
- if (!kvm_ro && __get_user_pages_fast(hva, 1, 1, &page) == 1) {
+ if (!kvm_ro && get_user_page_fast_only(hva, FOLL_WRITE, &page)) {
upgrade_write = true;
} else {
unsigned long pfn;
diff --git a/arch/powerpc/perf/callchain_64.c b/arch/powerpc/perf/callchain_64.c
index 1bff896d..814d1c2 100644
--- a/arch/powerpc/perf/callchain_64.c
+++ b/arch/powerpc/perf/callchain_64.c
@@ -29,11 +29,9 @@ int read_user_stack_slow(void __user *ptr, void *buf, int nb)
unsigned long addr = (unsigned long) ptr;
unsigned long offset;
struct page *page;
- int nrpages;
void *kaddr;
- nrpages = __get_user_pages_fast(addr, 1, 1, &page);
- if (nrpages == 1) {
+ if (get_user_page_fast_only(addr, FOLL_WRITE, &page)) {
kaddr = page_address(page);
/* align address to page boundary */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 93d93bd..c1718df 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1817,10 +1817,16 @@ extern int mprotect_fixup(struct vm_area_struct *vma,
/*
* doesn't attempt to fault and will return short.
*/
-int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
- struct page **pages);
+int get_user_pages_fast_only(unsigned long start, int nr_pages,
+unsigned int gup_flags, struct page **pages);
int pin_user_pages_fast_only(unsigned long start, int nr_pages,
unsigned int gup_flags, struct page **pages);
+
+static inline bool get_user_page_fast_only(unsigned long addr,
+ unsigned int gup_flags, struct page **pagep)
+{
+ return get_user_pages_fast_only(addr, 1, gup_flags, pagep) == 1;
+}
/*
* per-process(per-mm_struct) statistics.
*/
diff --git a/kernel/events/core.c b/kernel/events/core.c
index c94eb27..856d98c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6934,12 +6934,12 @@ static u64 perf_virt_to_phys(u64 virt)
* Walking the pages tables for user address.
* Interrupts are disabled, so it prevents any tear down
* of the page tables.
-* Try IRQ-safe __get_user_pages_fast first.
+* Try IRQ-safe get_user_page_fast_only first.
* If failed, leave phys_addr as 0.
*/
if (current->mm != NULL) {
pagefault_disable();
- if (__get_user_pages_fast(virt, 1, 0, &p) == 1)
+ if (get_user_page_fast_only(virt, 0, &p))
phys_addr = page_to_phys(p) + virt % PAGE_SIZE;
pagefault_enable();
}
diff --git a/mm/gup.c b/mm/gup.c
index 80f51a36..f4b05f3 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2278,7 +2278,7 @@ static int gup_pte_range(
[PATCH] ASoC: fsl_asrc: Fix -Wmissing-prototypes warning
From: shengjiu wang
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
sound/soc/fsl/fsl_asrc.c:557:18: warning: no previous prototype for function
'fsl_asrc_get_dma_channel' [-Wmissing-prototypes]
struct dma_chan *fsl_asrc_get_dma_channel(struct fsl_asrc_pair *pair, bool dir)
^
sound/soc/fsl/fsl_asrc.c:557:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
struct dma_chan *fsl_asrc_get_dma_channel(struct fsl_asrc_pair *pair, bool dir)
^
static
Fixes: be7bd03f0201 ("ASoC: fsl_asrc: Move common definition to
fsl_asrc_common")
Reported-by: kbuild test robot
Signed-off-by: shengjiu wang
---
sound/soc/fsl/fsl_asrc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 7e2d598ffb81..d79d2c7f8d36 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -554,7 +554,8 @@ static void fsl_asrc_stop_pair(struct fsl_asrc_pair *pair)
/**
* Get DMA channel according to the pair and direction.
*/
-struct dma_chan *fsl_asrc_get_dma_channel(struct fsl_asrc_pair *pair, bool dir)
+static struct dma_chan *fsl_asrc_get_dma_channel(struct fsl_asrc_pair *pair,
+bool dir)
{
struct fsl_asrc *asrc = pair->asrc;
enum asrc_pair_index index = pair->index;
@@ -564,7 +565,6 @@ struct dma_chan *fsl_asrc_get_dma_channel(struct
fsl_asrc_pair *pair, bool dir)
return dma_request_slave_channel(&asrc->pdev->dev, name);
}
-EXPORT_SYMBOL_GPL(fsl_asrc_get_dma_channel);
static int fsl_asrc_dai_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
--
2.21.0
Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
Hi Michael, On 01. 04. 20 13:30, Michal Simek wrote: > On 01. 04. 20 12:38, Takashi Iwai wrote: >> On Wed, 01 Apr 2020 12:35:16 +0200, >> Michael Ellerman wrote: >>> >>> Michal Simek writes: On 01. 04. 20 4:07, Michael Ellerman wrote: > Michal Simek writes: >> Hi, >> >> recently we wanted to update xilinx intc driver and we found that >> function >> which we wanted to remove is still wired by ancient Xilinx PowerPC >> platforms. Here is the thread about it. >> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/ >> >> I have been talking about it internally and there is no interest in these >> platforms and it is also orphan for quite a long time. None is really >> running/testing these platforms regularly that's why I think it makes >> sense >> to remove them also with drivers which are specific to this platform. >> >> U-Boot support was removed in 2017 without anybody complain about it >> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed >> >> Based on current ppc/next. >> >> If anyone has any objection about it, please let me know. > > Thanks for taking the time to find all this code and remove it. > > I'm not going to take this series for v5.7, it was posted too close to > the merge window, and doing so wouldn't give people much time to object, > especially given people are distracted at the moment. > > I'm happy to take it for v5.8, assuming there's no major objections. Sure. Just to let you know Christophe Leroy included this patch in his series about ppc405 removal. It should be the same. If you don't want to take that alsa patch I can send it separately and this patch can be taken from his series. I don't really mind but please let me know what way you prefer. >>> >>> It's better to keep it all together, so I'm happy take the alsa patch as >>> well, it's already been acked. >> >> Sure, please go ahead. > > > g8. Can you please take this series? I know that there is v5 from Christophe which has this 1/2 as 1/13. But I need this alsa patch too and I would like to close this because it is around for almost 2 months and none raised a concern about removing just these Xilinx platforms. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs signature.asc Description: OpenPGP digital signature
[PATCH v10 0/5] powerpc/hv-24x7: Expose chip/sockets info to add json file metric support for the hv_24x7 socket/chip level events
Patchset fixes the inconsistent results we are getting when we run multiple 24x7 events. "hv_24x7" pmu interface events needs system dependent parameter like socket/chip/core. For example, hv_24x7 chip level events needs specific chip-id to which the data is requested should be added as part of pmu events. So to enable JSON file support to "hv_24x7" interface, patchset expose total number of sockets and chips per-socket details in sysfs files (sockets, chips) under "/sys/devices/hv_24x7/interface/". To get number of sockets, chips per sockets and cores per chip patchset adds a rtas call with token "PROCESSOR_MODULE_INFO" to get these details. Patchset also handles partition migration case to re-init these system depended parameters by adding proper calls in post_mobility_fixup()(mobility.c). Changelog: v9 -> v10 - Change function name from 'read_sys_info_pseries()' to 'read_24x7_sys_info()'. - Remove rtas_local_data_buf use, as we can directly use rtas_data_buf itself as we just need to do few loads and it also remove overload of memcpy in the lock Suggested by: Michael Ellerman. - Move part of updating 24x7 system info variables inside 'rtas_data_buf_lock' and make sure we release spinlock in each case. - Added Tested-by: Madhavan Srinivasan tag for patch 1 v8 -> v9 - As we not need 8k data buffer we also not require new lock and buffer size. So, removed that part. - Since we are using rtas_data_buf itself for rtas call, Switch to kmalloc for data buffer so that we can free that memory. - Made more changes as suggested by Nathan Lynch. v7 -> v8 - Add support for exposing cores per details as well. Suggested by: Madhavan Srinivasan. - Remove config check for 'CONFIG_PPC_RTAS' in previous implementation and address other comments by Michael Ellerman. v6 -> v7 - Split patchset into two patch series, one with kernel changes and another with perf tool side changes. This pachset contain all kernel side changes. Kajol Jain (5): powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details powerpc/hv-24x7: Add sysfs files inside hv-24x7 device to show processor details Documentation/ABI: Add ABI documentation for chips and sockets powerpc/pseries: Update hv-24x7 information after migration .../sysfs-bus-event_source-devices-hv_24x7| 21 arch/powerpc/include/asm/rtas.h | 6 ++ arch/powerpc/perf/hv-24x7.c | 98 +-- arch/powerpc/platforms/pseries/mobility.c | 3 + 4 files changed, 118 insertions(+), 10 deletions(-) -- 2.18.2
[PATCH v10 1/5] powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run
Commit 2b206ee6b0df ("powerpc/perf/hv-24x7: Display change in counter
values")' added to print _change_ in the counter value rather then raw
value for 24x7 counters. Incase of transactions, the event count
is set to 0 at the beginning of the transaction. It also sets
the event's prev_count to the raw value at the time of initialization.
Because of setting event count to 0, we are seeing some weird behaviour,
whenever we run multiple 24x7 events at a time.
For example:
command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/,
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}"
-C 0 -I 1000 sleep 100
1.000121704120 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
1.000121704 5 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
2.000357733 8 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
2.000357733 10 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
3.000495215 18,446,744,073,709,551,616
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
3.000495215 18,446,744,073,709,551,616
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
4.000641884 56 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
4.000641884 18,446,744,073,709,551,616
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
5.000791887 18,446,744,073,709,551,616
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
Getting these large values in case we do -I.
As we are setting event_count to 0, for interval case, overall event_count is
not
coming in incremental order. As we may can get new delta lesser then previous
count.
Because of which when we print intervals, we are getting negative value which
create
these large values.
This patch removes part where we set event_count to 0 in function
'h_24x7_event_read'. There won't be much impact as we do set
event->hw.prev_count
to the raw value at the time of initialization to print change value.
With this patch
In power9 platform
command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/,
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}"
-C 0 -I 1000 sleep 100
1.000117685 93 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
1.000117685 1 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
2.000349331 98 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
2.000349331 2 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
3.000495900131 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
3.000495900 4 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
4.000645920204 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
4.000645920 61 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
4.284169997 22 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
Signed-off-by: Kajol Jain
Suggested-by: Sukadev Bhattiprolu
Tested-by: Madhavan Srinivasan
---
arch/powerpc/perf/hv-24x7.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 573e0b309c0c..48e8f4b17b91 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1400,16 +1400,6 @@ static void h_24x7_event_read(struct perf_event *event)
h24x7hw = &get_cpu_var(hv_24x7_hw);
h24x7hw->events[i] = event;
put_cpu_var(h24x7hw);
- /*
-* Clear the event count so we can compute the _change_
-* in the 24x7 raw counter value at the end of the txn.
-*
-* Note that we could alternatively read the 24x7 value
-* now and save its value in event->hw.prev_count. But
-* that would require issuing a hcall, which would then
-* defeat the purpose of using the txn interface.
-*/
- local64_set(&event->count, 0);
}
put_cpu_var(hv_24x7_reqb);
--
2.18.2
[PATCH v10 2/5] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details
For hv_24x7 socket/chip level events, specific chip-id to which
the data requested should be added as part of pmu events.
But number of chips/socket in the system details are not exposed.
Patch implements read_24x7_sys_info() to get system
parameter values like number of sockets, cores per chip and
chips per socket. Rtas_call with token "PROCESSOR_MODULE_INFO"
is used to get these values.
Sub-sequent patch exports these values via sysfs.
Patch also make these parameters default to 1
Signed-off-by: Kajol Jain
---
arch/powerpc/include/asm/rtas.h | 6
arch/powerpc/perf/hv-24x7.c | 64 +
2 files changed, 70 insertions(+)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 3c1887351c71..7ef81b3e33f6 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -483,5 +483,11 @@ static inline void rtas_initialize(void) { };
extern int call_rtas(const char *, int, int, unsigned long *, ...);
+#ifdef CONFIG_HV_PERF_CTRS
+void read_24x7_sys_info(void);
+#else
+static inline void read_24x7_sys_info(void) { }
+#endif
+
#endif /* __KERNEL__ */
#endif /* _POWERPC_RTAS_H */
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 48e8f4b17b91..5cd954af5445 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#include "hv-24x7.h"
#include "hv-24x7-catalog.h"
#include "hv-common.h"
@@ -57,6 +58,67 @@ static bool is_physical_domain(unsigned domain)
}
}
+/*
+ * The Processor Module Information system parameter allows transferring
+ * of certain processor module information from the platform to the OS.
+ * Refer PAPR+ document to get parameter token value as '43'.
+ */
+
+#define PROCESSOR_MODULE_INFO 43
+
+static u32 phys_sockets; /* Physical sockets */
+static u32 phys_chipspersocket;/* Physical chips per socket*/
+static u32 phys_coresperchip; /* Physical cores per chip */
+
+/*
+ * read_24x7_sys_info()
+ * Retrieve the number of sockets and chips per socket and cores per
+ * chip details through the get-system-parameter rtas call.
+ */
+void read_24x7_sys_info(void)
+{
+ int call_status, len, ntypes;
+
+ spin_lock(&rtas_data_buf_lock);
+
+ /*
+* Making system parameter: chips and sockets and cores per chip
+* default to 1.
+*/
+ phys_sockets = 1;
+ phys_chipspersocket = 1;
+ phys_coresperchip = 1;
+
+ call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
+ NULL,
+ PROCESSOR_MODULE_INFO,
+ __pa(rtas_data_buf),
+ RTAS_DATA_BUF_SIZE);
+
+ rtas_data_buf[RTAS_DATA_BUF_SIZE - 1] = '\0';
+
+ if (call_status != 0) {
+ pr_err("Error calling get-system-parameter %d\n",
+ call_status);
+ } else {
+ len = be16_to_cpup((__be16 *)&rtas_data_buf[0]);
+ if (len < 8)
+ goto out;
+
+ ntypes = be16_to_cpup((__be16 *)&rtas_data_buf[2]);
+
+ if (!ntypes)
+ goto out;
+
+ phys_sockets = be16_to_cpup((__be16 *)&rtas_data_buf[4]);
+ phys_chipspersocket = be16_to_cpup((__be16 *)&rtas_data_buf[6]);
+ phys_coresperchip = be16_to_cpup((__be16 *)&rtas_data_buf[8]);
+ }
+
+out:
+ spin_unlock(&rtas_data_buf_lock);
+}
+
/* Domains for which more than one result element are returned for each event.
*/
static bool domain_needs_aggregation(unsigned int domain)
{
@@ -1605,6 +1667,8 @@ static int hv_24x7_init(void)
if (r)
return r;
+ read_24x7_sys_info();
+
return 0;
}
--
2.18.2
[PATCH v10 3/5] powerpc/hv-24x7: Add sysfs files inside hv-24x7 device to show processor details
To expose the system dependent parameter like total number of
sockets and numbers of chips per socket, patch adds two sysfs files.
"sockets" and "chips" are added to /sys/devices/hv_24x7/interface/
of the "hv_24x7" pmu.
Signed-off-by: Kajol Jain
---
arch/powerpc/perf/hv-24x7.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 5cd954af5445..995dd170ca4b 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -448,6 +448,24 @@ static ssize_t device_show_string(struct device *dev,
return sprintf(buf, "%s\n", (char *)d->var);
}
+static ssize_t sockets_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", phys_sockets);
+}
+
+static ssize_t chipspersocket_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", phys_chipspersocket);
+}
+
+static ssize_t coresperchip_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", phys_coresperchip);
+}
+
static struct attribute *device_str_attr_create_(char *name, char *str)
{
struct dev_ext_attribute *attr = kzalloc(sizeof(*attr), GFP_KERNEL);
@@ -1094,6 +1112,9 @@ PAGE_0_ATTR(catalog_len, "%lld\n",
(unsigned long long)be32_to_cpu(page_0->length) * 4096);
static BIN_ATTR_RO(catalog, 0/* real length varies */);
static DEVICE_ATTR_RO(domains);
+static DEVICE_ATTR_RO(sockets);
+static DEVICE_ATTR_RO(chipspersocket);
+static DEVICE_ATTR_RO(coresperchip);
static struct bin_attribute *if_bin_attrs[] = {
&bin_attr_catalog,
@@ -1104,6 +1125,9 @@ static struct attribute *if_attrs[] = {
&dev_attr_catalog_len.attr,
&dev_attr_catalog_version.attr,
&dev_attr_domains.attr,
+ &dev_attr_sockets.attr,
+ &dev_attr_chipspersocket.attr,
+ &dev_attr_coresperchip.attr,
NULL,
};
--
2.18.2
[PATCH v10 4/5] Documentation/ABI: Add ABI documentation for chips and sockets
Add documentation for the following sysfs files: /sys/devices/hv_24x7/interface/chipspersocket, /sys/devices/hv_24x7/interface/sockets, /sys/devices/hv_24x7/interface/coresperchip Signed-off-by: Kajol Jain --- .../sysfs-bus-event_source-devices-hv_24x7| 21 +++ 1 file changed, 21 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 index ec27c6c9e737..e8698afcd952 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 @@ -22,6 +22,27 @@ Description: Exposes the "version" field of the 24x7 catalog. This is also extractable from the provided binary "catalog" sysfs entry. +What: /sys/devices/hv_24x7/interface/sockets +Date: May 2020 +Contact: Linux on PowerPC Developer List +Description: read only + This sysfs interface exposes the number of sockets present in the + system. + +What: /sys/devices/hv_24x7/interface/chipspersocket +Date: May 2020 +Contact: Linux on PowerPC Developer List +Description: read only + This sysfs interface exposes the number of chips per socket + present in the system. + +What: /sys/devices/hv_24x7/interface/coresperchip +Date: May 2020 +Contact: Linux on PowerPC Developer List +Description: read only + This sysfs interface exposes the number of cores per chip + present in the system. + What: /sys/bus/event_source/devices/hv_24x7/event_descs/ Date: February 2014 Contact: Linux on PowerPC Developer List -- 2.18.2
[PATCH v10 5/5] powerpc/pseries: Update hv-24x7 information after migration
Function 'read_sys_info_pseries()' is added to get system parameter values like number of sockets and chips per socket. and it gets these details via rtas_call with token "PROCESSOR_MODULE_INFO". Incase lpar migrate from one system to another, system parameter details like chips per sockets or number of sockets might change. So, it needs to be re-initialized otherwise, these values corresponds to previous system values. This patch adds a call to 'read_sys_info_pseries()' from 'post-mobility_fixup()' to re-init the physsockets and physchips values Signed-off-by: Kajol Jain --- arch/powerpc/platforms/pseries/mobility.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c index b571285f6c14..10d982997736 100644 --- a/arch/powerpc/platforms/pseries/mobility.c +++ b/arch/powerpc/platforms/pseries/mobility.c @@ -371,6 +371,9 @@ void post_mobility_fixup(void) /* Possibly switch to a new RFI flush type */ pseries_setup_rfi_flush(); + /* Reinitialise system information for hv-24x7 */ + read_24x7_sys_info(); + return; } -- 2.18.2
Re: [PATCH v4 07/45] powerpc/ptdump: Limit size of flags text to 1/2 chars on PPC32
Le 25/05/2020 à 07:15, Michael Ellerman a écrit : Christophe Leroy writes: In order to have all flags fit on a 80 chars wide screen, reduce the flags to 1 char (2 where ambiguous). I don't love this, the output is less readable. Is fitting on an 80 char screen a real issue for you? I just make my terminal window bigger. I don't have strong opinion about that, and the terminal can be made bigger. I just don't like how messy it is, some flags are so big that they hide other ones and getting it more ordered and more compact helped me during all the verifications I did with this series, but we can leave it as is if you prefer. Would you like a v5 without patches 7 and 8 ? Or I can just resend the patches that will be impacted, that is 9 and 38 ? Without the changes I get: ---[ Start of kernel VM ]--- 0xc000-0xc0ff 0x16M huge shared rX present accessed 0xc100-0xc7ff 0x0100 112M huge shared rw present dirty accessed ---[ vmalloc() Area ]--- 0xc900-0xc9003fff 0x050e400016K shared rw present dirty accessed 0xc9008000-0xc900bfff 0x050ec00016K shared rw present dirty accessed 0xc901-0xc9013fff 0xd00016K shared rw present guarded dirty accessed no cache 0xc9018000-0xc901bfff 0x050f16K shared rw present dirty accessed ---[ Fixmap start ]--- 0xf7f0-0xf7f7 0xff00 512K huge shared rw present guarded dirty accessed no cache ---[ Fixmap end ]--- ---[ kasan shadow mem start ]--- 0xf800-0xf8ff 0x070016M huge shared rw present dirty accessed 0xf900-0xf91f [0x01288000] 16K shared r present accessed 0xf920-0xf9203fff 0x050e16K shared rw present dirty accessed With the change I get. ---[ Start of kernel VM ]--- 0xc000-0xc0ff 0x16M h r x psh a 0xc100-0xc7ff 0x0100 112M h rw psh d a ---[ vmalloc() Area ]--- 0xc900-0xc9003fff 0x050e400016K rw psh d a 0xc9008000-0xc900bfff 0x050ec00016K rw psh d a 0xc901-0xc9013fff 0xd00016K rw p i g sh d a 0xc9018000-0xc901bfff 0x050f16K rw psh d a ---[ Fixmap start ]--- 0xf7f0-0xf7f7 0xff00 512K h rw p i g sh d a ---[ Fixmap end ]--- ---[ kasan shadow mem start ]--- 0xf800-0xf8ff 0x070016M h rw psh d a 0xf900-0xf91f [0x01288000] 16K r psh a 0xf920-0xf9203fff 0x050e16K rw psh d a Christophe cheers No cache is 'i' User is 'ur' (Supervisor would be sr) Shared (for 8xx) becomes 'sh' (it was 'user' when not shared but that was ambiguous because that's not entirely right) Signed-off-by: Christophe Leroy --- arch/powerpc/mm/ptdump/8xx.c| 33 --- arch/powerpc/mm/ptdump/shared.c | 35 + 2 files changed, 35 insertions(+), 33 deletions(-)
Re: [RESEND PATCH v7 4/5] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods
Hi Ira, Mpe and Aneesh,
Vaibhav Jain writes:
> Michael Ellerman writes:
>
>> Ira Weiny writes:
>>> On Wed, May 20, 2020 at 12:30:57AM +0530, Vaibhav Jain wrote:
Introduce support for Papr nvDimm Specific Methods (PDSM) in papr_scm
modules and add the command family to the white list of NVDIMM command
sets. Also advertise support for ND_CMD_CALL for the dimm
command mask and implement necessary scaffolding in the module to
handle ND_CMD_CALL ioctl and PDSM requests that we receive.
>> ...
+ *
+ * Payload Version:
+ *
+ * A 'payload_version' field is present in PDSM header that indicates a
specific
+ * version of the structure present in PDSM Payload for a given PDSM
command.
+ * This provides backward compatibility in case the PDSM Payload structure
+ * evolves and different structures are supported by 'papr_scm' and
'libndctl'.
+ *
+ * When sending a PDSM Payload to 'papr_scm', 'libndctl' should send the
version
+ * of the payload struct it supports via 'payload_version' field. The
'papr_scm'
+ * module when servicing the PDSM envelope checks the 'payload_version'
and then
+ * uses 'payload struct version' == MIN('payload_version field',
+ * 'max payload-struct-version supported by papr_scm') to service the
PDSM.
+ * After servicing the PDSM, 'papr_scm' put the negotiated version of
payload
+ * struct in returned 'payload_version' field.
>>>
>>> FWIW many people believe using a size rather than version is more
>>> sustainable.
>>> It is expected that new payload structures are larger (more features) than
>>> the
>>> previous payload structure.
>>>
>>> I can't find references at the moment through.
>>
>> I think clone_args is a good modern example:
>>
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/sched.h#n88
>>
>> cheers
>
> Thank Ira and Mpe for pointing this out. I looked into how clone3 sycall
> handles clone_args and few differences came out:
>
> * Unlike clone_args that are always transferred in one direction from
> user-space to kernel, payload contents of pdsms are transferred in both
> directions. Having a single version number makes it easier for
> user-space and kernel to determine what data will be exchanged.
>
> * For PDSMs, the version number is negotiated between libndctl and
> kernel. For example in case kernel only supports an older version of
> a structure, its free to send a lower version number back to
> libndctl. Such negotiations doesnt happen with clone3 syscall.
If you are ok with the explaination above please let me know. I will
quickly spin off a v8 addressing your review comments.
Thanks,
--
Cheers
~ Vaibhav
Re: Endless soft-lockups for compiling workload since next-20200519
On Thu, May 21, 2020 at 02:41:14PM +0200, Frederic Weisbecker wrote:
> On Thu, May 21, 2020 at 01:00:27PM +0200, Peter Zijlstra wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 01f94cf52783..b6d8a7b991f0 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -10033,7 +10033,7 @@ static void kick_ilb(unsigned int flags)
> > * is idle. And the softirq performing nohz idle load balance
> > * will be run before returning from the IPI.
> > */
> > - smp_call_function_single_async(ilb_cpu, &cpu_rq(ilb_cpu)->nohz_csd);
> > + smp_call_function_single_async(ilb_cpu, &this_rq()->nohz_csd);
>
> My fear here is that if a previous call from the the same CPU but to another
> target is still pending, the new one will be spuriously ignored.
>
Urgh, indeed!
> But I believe we can still keep the remote csd if nohz_flags() are
> strictly only set before the IPI and strictly only cleared from it.
>
> And I still don't understand why trigger_load_balance() raise the
> softirq without setting the current CPU as ilb. run_rebalance_domains()
> thus ignores it most of the time in the end or it spuriously clear the
> nohz_flags set by an IPI sender. Or there is something I misunderstood
> there.
That is because it is simple and didn't matter before. Whoever got there
first go to run the ilb whenever the flag was set.
But now we have this race due to having to serialize access to the csd.
We want the IPI to clear the flag, but then the softirq no longer knows
it was supposed to do ILB.
How's this then?
---
include/linux/sched.h | 4
kernel/sched/core.c | 41 +
kernel/sched/fair.c | 15 +++
kernel/sched/sched.h | 2 +-
4 files changed, 25 insertions(+), 37 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f38d62c4632c..136ee400b568 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -696,6 +696,10 @@ struct task_struct {
struct uclamp_seuclamp[UCLAMP_CNT];
#endif
+#ifdef CONFIG_SMP
+ call_single_data_t wake_csd;
+#endif
+
#ifdef CONFIG_PREEMPT_NOTIFIERS
/* List of struct preempt_notifier: */
struct hlist_head preempt_notifiers;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5b286469e26e..90484b988b65 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -637,41 +637,25 @@ void wake_up_nohz_cpu(int cpu)
wake_up_idle_cpu(cpu);
}
-static inline bool got_nohz_idle_kick(void)
+static void nohz_csd_func(void *info)
{
- int cpu = smp_processor_id();
-
- if (!(atomic_read(nohz_flags(cpu)) & NOHZ_KICK_MASK))
- return false;
-
- if (idle_cpu(cpu) && !need_resched())
- return true;
+ struct rq *rq = info;
+ int cpu = cpu_of(rq);
+ WARN_ON(!(atomic_read(nohz_flags(cpu)) & NOHZ_KICK_MASK));
/*
-* We can't run Idle Load Balance on this CPU for this time so we
-* cancel it and clear NOHZ_BALANCE_KICK
+* Release the rq::nohz_csd.
*/
+ smp_mb__before_atomic();
atomic_andnot(NOHZ_KICK_MASK, nohz_flags(cpu));
- return false;
-}
-
-static void nohz_csd_func(void *info)
-{
- struct rq *rq = info;
- if (got_nohz_idle_kick()) {
- rq->idle_balance = 1;
+ rq->idle_balance = idle_cpu(cpu);
+ if (rq->idle_balance && !need_resched()) {
+ rq->nohz_idle_balance = 1;
raise_softirq_irqoff(SCHED_SOFTIRQ);
}
}
-#else /* CONFIG_NO_HZ_COMMON */
-
-static inline bool got_nohz_idle_kick(void)
-{
- return false;
-}
-
#endif /* CONFIG_NO_HZ_COMMON */
#ifdef CONFIG_NO_HZ_FULL
@@ -2320,7 +2304,7 @@ static void ttwu_queue_remote(struct task_struct *p, int
cpu, int wake_flags)
if (llist_add(&p->wake_entry, &rq->wake_list)) {
if (!set_nr_if_polling(rq->idle))
- smp_call_function_single_async(cpu, &rq->wake_csd);
+ smp_call_function_single_async(cpu, &p->wake_csd);
else
trace_sched_wake_idle_without_ipi(cpu);
}
@@ -2921,6 +2905,9 @@ int sched_fork(unsigned long clone_flags, struct
task_struct *p)
#endif
#if defined(CONFIG_SMP)
p->on_cpu = 0;
+ p->wake_csd = (struct __call_single_data) {
+ .func = wake_csd_func,
+ };
#endif
init_task_preempt_count(p);
#ifdef CONFIG_SMP
@@ -6723,8 +6710,6 @@ void __init sched_init(void)
rq->avg_idle = 2*sysctl_sched_migration_cost;
rq->max_idle_balance_cost = sysctl_sched_migration_cost;
- rq_csd_init(rq, &rq->wake_csd, wake_csd_func);
-
INIT_LIST_HEAD(&rq->cfs_tasks);
rq_attach_root(rq, &def_root_domain);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 01f94cf52783..93525549a023 1
Re: Endless soft-lockups for compiling workload since next-20200519
On Mon, May 25, 2020 at 03:21:05PM +0200, Peter Zijlstra wrote:
> @@ -2320,7 +2304,7 @@ static void ttwu_queue_remote(struct task_struct *p,
> int cpu, int wake_flags)
>
> if (llist_add(&p->wake_entry, &rq->wake_list)) {
> if (!set_nr_if_polling(rq->idle))
> - smp_call_function_single_async(cpu, &rq->wake_csd);
> + smp_call_function_single_async(cpu, &p->wake_csd);
> else
> trace_sched_wake_idle_without_ipi(cpu);
Ok that's of course very unlikely but could it be possible to have the
following:
CPU 0 CPU 1 CPU 2
-
//Wake up A
ttwu_queue(TASK A, CPU 1) idle_loop {
ttwu_queue_pending {
raw_spin_unlock_irqrestore(rq)
# VMEXIT (with IPI still pending)
//task
A migrates here
wait_event()
//sleep
//Wake up A
ttwu_queue(TASK A, CPU 2) {
//IPI on CPU 2 ignored
// due to csd->flags == CSD_LOCK
Re: Endless soft-lockups for compiling workload since next-20200519
On Mon, May 25, 2020 at 03:21:05PM +0200, Peter Zijlstra wrote: > - flags = atomic_fetch_andnot(NOHZ_KICK_MASK, nohz_flags(this_cpu)); > - if (!(flags & NOHZ_KICK_MASK)) > + if (idle != CPU_IDLE) > return false; > > _nohz_idle_balance(this_rq, flags, idle); Bah, I think I broke something there. Lemme go mend.
Re: Endless soft-lockups for compiling workload since next-20200519
On Mon, May 25, 2020 at 04:05:49PM +0200, Frederic Weisbecker wrote:
> On Mon, May 25, 2020 at 03:21:05PM +0200, Peter Zijlstra wrote:
> > @@ -2320,7 +2304,7 @@ static void ttwu_queue_remote(struct task_struct *p,
> > int cpu, int wake_flags)
> >
> > if (llist_add(&p->wake_entry, &rq->wake_list)) {
> > if (!set_nr_if_polling(rq->idle))
> > - smp_call_function_single_async(cpu, &rq->wake_csd);
> > + smp_call_function_single_async(cpu, &p->wake_csd);
> > else
> > trace_sched_wake_idle_without_ipi(cpu);
>
> Ok that's of course very unlikely but could it be possible to have the
> following:
>
> CPU 0 CPU 1 CPU 2
> -
>
> //Wake up A
> ttwu_queue(TASK A, CPU 1) idle_loop {
> ttwu_queue_pending {
>
> raw_spin_unlock_irqrestore(rq)
> # VMEXIT (with IPI still pending)
>
> //task A migrates here
>
> wait_event()
>
> //sleep
>
> //Wake up A
> ttwu_queue(TASK A, CPU 2) {
> //IPI on CPU 2 ignored
> // due to csd->flags == CSD_LOCK
>
Right you are.
Bah!
More thinking
Re: [PATCH] ASoC: fsl_asrc: Merge suspend/resume function to runtime_suspend/resume
On Fri, 22 May 2020 17:57:24 +0800, Shengjiu Wang wrote: > With dedicated power domain for asrc, power can be disabled after > probe and pm runtime suspend, then the value of all registers need to > be restored in pm runtime resume. So we can merge suspend/resume function > to runtime_suspend/resume function and enable regcache only in end of > probe. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_asrc: Merge suspend/resume function to runtime_suspend/resume commit: 393dc21d0f25e8fcde8baca78b8a38afe61db2a7 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl_asrc: Fix -Wmissing-prototypes warning
On Mon, 25 May 2020 17:03:32 +0800, Shengjiu Wang wrote: > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 > > sound/soc/fsl/fsl_asrc.c:557:18: warning: no previous prototype for function > 'fsl_asrc_get_dma_channel' [-Wmissing-prototypes] > struct dma_chan *fsl_asrc_get_dma_channel(struct fsl_asrc_pair *pair, bool > dir) > ^ > sound/soc/fsl/fsl_asrc.c:557:1: note: declare 'static' if the function is not > intended to be used outside of this translation unit > struct dma_chan *fsl_asrc_get_dma_channel(struct fsl_asrc_pair *pair, bool > dir) > ^ > static Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_asrc: Fix -Wmissing-prototypes warning commit: cff1f8b4f8e119a9dbd9872d7a04fedef8d0c1a2 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] ASoC: fsl: imx-audmix: Fix unused assignment to variable 'ret'
On Wed, 13 May 2020 19:14:08 +0800, Tang Bin wrote: > Omit unused initialized value, because 'ret' will be assigined > by the function snd_soc_component_read(). Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl: imx-audmix: Fix unused assignment to variable 'ret' commit: 085c02d355ac585184ef4f00eb333cd86f6add80 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
[PATCH] ASoC: fsl_asrc_dma: Fix dma_chan leak when config DMA channel failed
fsl_asrc_dma_hw_params() invokes dma_request_channel() or
fsl_asrc_get_dma_channel(), which returns a reference of the specified
dma_chan object to "pair->dma_chan[dir]" with increased refcnt.
The reference counting issue happens in one exception handling path of
fsl_asrc_dma_hw_params(). When config DMA channel failed for Back-End,
the function forgets to decrease the refcnt increased by
dma_request_channel() or fsl_asrc_get_dma_channel(), causing a refcnt
leak.
Fix this issue by calling dma_release_channel() when config DMA channel
failed.
Signed-off-by: Xiyu Yang
Signed-off-by: Xin Tan
---
sound/soc/fsl/fsl_asrc_dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index e7178817d7a7..1ee10eafe3e6 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c
@@ -252,6 +252,7 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component
*component,
ret = dmaengine_slave_config(pair->dma_chan[dir], &config_be);
if (ret) {
dev_err(dev, "failed to config DMA channel for Back-End\n");
+ dma_release_channel(pair->dma_chan[dir]);
return ret;
}
--
2.7.4
Re: [PATCH] powerpc: Add ppc_inst_as_u64()
On Mon, May 25, 2020 at 3:49 PM Michael Ellerman wrote:
>
> The code patching code wants to get the value of a struct ppc_inst as
Might need to change the wording here as it also gets used in
arch_prepare_optimized_kprobe()
> a u64 when the instruction is prefixed, so we can pass the u64 down to
> __put_user_asm() and write it with a single store.
>
> This is a bit awkward because the value differs based on the CPU
> endianness, so add a helper to do the conversion.
>
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/include/asm/inst.h | 9 +
> arch/powerpc/kernel/optprobes.c | 3 +--
> arch/powerpc/lib/code-patching.c | 8 +---
> 3 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
> index d82e0c99cfa1..d61e07fb2937 100644
> --- a/arch/powerpc/include/asm/inst.h
> +++ b/arch/powerpc/include/asm/inst.h
> @@ -100,6 +100,15 @@ static inline int ppc_inst_len(struct ppc_inst x)
> return ppc_inst_prefixed(x) ? 8 : 4;
> }
>
> +static inline u64 ppc_inst_as_u64(struct ppc_inst x)
> +{
> +#ifdef CONFIG_CPU_LITTLE_ENDIAN
> + return (u64)ppc_inst_suffix(x) << 32 | ppc_inst_val(x);
> +#else
> + return (u64)ppc_inst_val(x) << 32 | ppc_inst_suffix(x);
> +#endif
> +}
> +
> int probe_user_read_inst(struct ppc_inst *inst,
> struct ppc_inst __user *nip);
>
> diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
> index 3ac105e7faae..69bfe96884e2 100644
> --- a/arch/powerpc/kernel/optprobes.c
> +++ b/arch/powerpc/kernel/optprobes.c
> @@ -283,8 +283,7 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe
> *op, struct kprobe *p)
> * 3. load instruction to be emulated into relevant register, and
> */
> temp = ppc_inst_read((struct ppc_inst *)p->ainsn.insn);
> - patch_imm64_load_insns(ppc_inst_val(temp) |
> ((u64)ppc_inst_suffix(temp) << 32),
> - 4, buff + TMPL_INSN_IDX);
> + patch_imm64_load_insns(ppc_inst_as_u64(temp), 4, buff +
> TMPL_INSN_IDX);
>
> /*
> * 4. branch back from trampoline
> diff --git a/arch/powerpc/lib/code-patching.c
> b/arch/powerpc/lib/code-patching.c
> index 64cf621e5b00..5ecf0d635a8d 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -27,13 +27,7 @@ static int __patch_instruction(struct ppc_inst *exec_addr,
> struct ppc_inst instr
> if (!ppc_inst_prefixed(instr)) {
> __put_user_asm(ppc_inst_val(instr), patch_addr, err, "stw");
> } else {
> -#ifdef CONFIG_CPU_LITTLE_ENDIAN
> - __put_user_asm((u64)ppc_inst_suffix(instr) << 32 |
> - ppc_inst_val(instr), patch_addr, err, "std");
> -#else
> - __put_user_asm((u64)ppc_inst_val(instr) << 32 |
> - ppc_inst_suffix(instr), patch_addr, err,
> "std");
> -#endif
> + __put_user_asm(ppc_inst_as_u64(instr), patch_addr, err,
> "std");
> }
>
> if (err)
> --
> 2.25.1
>
I booted a BE and LE kernel - test_prefixed_patching() worked on both.
Also on BE and LE kernels I put optprobes on prefixed and non prefixed
instructions.
The correct value was passed via r4 to emulate_step().
Tested-by: Jordan Niethe
Re: [PATCH] net/ethernet/freescale: rework quiesce/activate for ucc_geth
Le 23.05.2020 à 00:50, David Miller a écrit : From: Valentin Longchamp Date: Wed, 20 May 2020 17:53:50 +0200 ugeth_quiesce/activate are used to halt the controller when there is a link change that requires to reconfigure the mac. The previous implementation called netif_device_detach(). This however causes the initial activation of the netdevice to fail precisely because it's detached. For details, see [1]. A possible workaround was the revert of commit net: linkwatch: add check for netdevice being present to linkwatch_do_dev However, the check introduced in the above commit is correct and shall be kept. The netif_device_detach() is thus replaced with netif_tx_stop_all_queues() that prevents any tranmission. This allows to perform mac config change required by the link change, without detaching the corresponding netdevice and thus not preventing its initial activation. [1] https://lists.openwall.net/netdev/2020/01/08/201 Signed-off-by: Valentin Longchamp Acked-by: Matteo Ghidoni Applied, thanks. Thanks David. May I suggest that this get backported to stable until (including) the 4.19 stable release ? As the above mentioned commit, merged for 4.19, 124eee3f6955 net: linkwatch: add check for netdevice being present to linkwatch_do_dev does indeed break the ucc_geth driver, this patch can be considered as a bugfix that should be taken into account for stable.
Re: [PATCH v4 3/7] KVM: PPC: Remove redundant kvm_run from vcpu_arch
On Mon, Apr 27, 2020 at 12:35:10PM +0800, Tianjia Zhang wrote: > The 'kvm_run' field already exists in the 'vcpu' structure, which > is the same structure as the 'kvm_run' in the 'vcpu_arch' and > should be deleted. > > Signed-off-by: Tianjia Zhang This looks fine. I assume each architecture sub-maintainer is taking the relevant patches from this series via their tree - is that right? Reviewed-by: Paul Mackerras
Re: [PATCH v4 4/7] KVM: PPC: clean up redundant 'kvm_run' parameters
On Mon, Apr 27, 2020 at 12:35:11PM +0800, Tianjia Zhang wrote: > In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu' > structure. For historical reasons, many kvm-related function parameters > retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This > patch does a unified cleanup of these remaining redundant parameters. > > Signed-off-by: Tianjia Zhang This looks OK, though possibly a little larger than it needs to be because of variable name changes (kvm_run -> run) that aren't strictly necessary. Reviewed-by: Paul Mackerras
Re: [PATCH v4 5/7] KVM: PPC: clean up redundant kvm_run parameters in assembly
On Mon, Apr 27, 2020 at 12:35:12PM +0800, Tianjia Zhang wrote: > In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu' > structure. For historical reasons, many kvm-related function parameters > retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This > patch does a unified cleanup of these remaining redundant parameters. Some of these changes don't look completely correct to me, see below. If you're expecting these patches to go through my tree, I can fix up the patch and commit it (with you as author), noting the changes I made in the commit message. Do you want me to do that? > diff --git a/arch/powerpc/kvm/book3s_interrupts.S > b/arch/powerpc/kvm/book3s_interrupts.S > index f7ad99d972ce..0eff749d8027 100644 > --- a/arch/powerpc/kvm/book3s_interrupts.S > +++ b/arch/powerpc/kvm/book3s_interrupts.S > @@ -55,8 +55,7 @@ > > / > > /* Registers: > - * r3: kvm_run pointer > - * r4: vcpu pointer > + * r3: vcpu pointer > */ > _GLOBAL(__kvmppc_vcpu_run) > > @@ -68,8 +67,8 @@ kvm_start_entry: > /* Save host state to the stack */ > PPC_STLU r1, -SWITCH_FRAME_SIZE(r1) > > - /* Save r3 (kvm_run) and r4 (vcpu) */ > - SAVE_2GPRS(3, r1) > + /* Save r3 (vcpu) */ > + SAVE_GPR(3, r1) > > /* Save non-volatile registers (r14 - r31) */ > SAVE_NVGPRS(r1) > @@ -82,11 +81,11 @@ kvm_start_entry: > PPC_STL r0, _LINK(r1) > > /* Load non-volatile guest state from the vcpu */ > - VCPU_LOAD_NVGPRS(r4) > + VCPU_LOAD_NVGPRS(r3) > > kvm_start_lightweight: > /* Copy registers into shadow vcpu so we can access them in real mode */ > - mr r3, r4 > + mr r4, r3 This mr doesn't seem necessary. > bl FUNC(kvmppc_copy_to_svcpu) > nop > REST_GPR(4, r1) This should be loading r4 from GPR3(r1), not GPR4(r1) - which is what REST_GPR(4, r1) will do. Then, in the file but not in the patch context, there is this line: PPC_LL r3, GPR4(r1)/* vcpu pointer */ where once again GPR4 needs to be GPR3. > @@ -191,10 +190,10 @@ after_sprg3_load: > PPC_STL r31, VCPU_GPR(R31)(r7) > > /* Pass the exit number as 3rd argument to kvmppc_handle_exit */ The comment should be modified to say "2nd" instead of "3rd", otherwise it is confusing. The rest of the patch looks OK. Paul.
[PATCH] powerpc/64s: Fix restore of NV GPRs after facility unavailable exception
Commit 702f09805222 ("powerpc/64s/exception: Remove lite interrupt
return") changed the interrupt return path to not restore non-volatile
registers by default, and explicitly restore them in paths where it is
required.
But it missed that the facility unavailable exception can sometimes
modify user registers, ie. when it does emulation of move from DSCR.
This is seen as a failure of the dscr_sysfs_thread_test:
test: dscr_sysfs_thread_test
[cpu 0] User DSCR should be 1 but is 0
failure: dscr_sysfs_thread_test
So restore non-volatile GPRs after facility unavailable exceptions.
Currently the hypervisor facility unavailable exception is also wired
up to call facility_unavailable_exception().
In practice we should never take a hypervisor facility unavailable
exception for the DSCR. On older bare metal systems we set HFSCR_DSCR
unconditionally in __init_HFSCR, or on newer systems it should be
enabled via the "data-stream-control-register" device tree CPU
feature.
Even if it's not, since commit f3c99f97a3cd ("KVM: PPC: Book3S HV:
Don't access HFSCR, LPIDR or LPCR when running nested"), the KVM code
has unconditionally set HFSCR_DSCR when running guests.
So we should only get a hypervisor facility unavailable for the DSCR
if skiboot has disabled the "data-stream-control-register" feature,
and we are somehow in guest context but not via KVM.
Given all that, it should be unnecessary to add a restore of
non-volatile GPRs after the hypervisor facility exception, because we
never expect to hit that path. But equally we may as well add the
restore, because we never expect to hit that path, and if we ever did,
at least we would correctly restore the registers to their post
emulation state.
In future we can split the non-HV and HV facility unavailable handling
so that there is no emulation in the HV handler, and then remove the
restore for the HV case.
Fixes: 702f09805222 ("powerpc/64s/exception: Remove lite interrupt return")
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/exceptions-64s.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index 0801cd0e6012..72036082dbaf 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -2436,6 +2436,7 @@ EXC_COMMON_BEGIN(facility_unavailable_common)
GEN_COMMON facility_unavailable
addir3,r1,STACK_FRAME_OVERHEAD
bl facility_unavailable_exception
+ REST_NVGPRS(r1) /* instruction emulation may change GPRs */
b interrupt_return
GEN_KVM facility_unavailable
@@ -2465,6 +2466,7 @@ EXC_COMMON_BEGIN(h_facility_unavailable_common)
GEN_COMMON h_facility_unavailable
addir3,r1,STACK_FRAME_OVERHEAD
bl facility_unavailable_exception
+ REST_NVGPRS(r1) /* XXX Shouldn't be necessary in practice */
b interrupt_return
GEN_KVM h_facility_unavailable
--
2.25.1
[PATCH] powerpc/64: Remove unused generic_secondary_thread_init()
The last caller was removed in 2014 in commit fb5a515704d7 ("powerpc:
Remove platforms/wsp and associated pieces").
Once generic_secondary_thread_init() is removed there are no longer
any uses of book3e_secondary_thread_init() or
generic_secondary_common_init so remove them too.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/smp.h | 1 -
arch/powerpc/kernel/exceptions-64e.S | 4
arch/powerpc/kernel/head_64.S| 18 --
3 files changed, 23 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 49a25e2400f2..81a49566ccd8 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -243,7 +243,6 @@ extern void arch_send_call_function_ipi_mask(const struct
cpumask *mask);
* 64-bit but defining them all here doesn't harm
*/
extern void generic_secondary_smp_init(void);
-extern void generic_secondary_thread_init(void);
extern unsigned long __secondary_hold_spinloop;
extern unsigned long __secondary_hold_acknowledge;
extern char __secondary_hold;
diff --git a/arch/powerpc/kernel/exceptions-64e.S
b/arch/powerpc/kernel/exceptions-64e.S
index d9ed79415100..9f9e8686798b 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -1814,10 +1814,6 @@ _GLOBAL(book3e_secondary_core_init)
1: mtlrr28
blr
-_GLOBAL(book3e_secondary_thread_init)
- mflrr28
- b 3b
-
.globl init_core_book3e
init_core_book3e:
/* Establish the interrupt vector base */
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 0e05a9a47a4b..4ae2c18c5fc6 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -302,23 +302,6 @@ _GLOBAL(fsl_secondary_thread_init)
1:
#endif
-_GLOBAL(generic_secondary_thread_init)
- mr r24,r3
-
- /* turn on 64-bit mode */
- bl enable_64b_mode
-
- /* get a valid TOC pointer, wherever we're mapped at */
- bl relative_toc
- tovirt(r2,r2)
-
-#ifdef CONFIG_PPC_BOOK3E
- /* Book3E initialization */
- mr r3,r24
- bl book3e_secondary_thread_init
-#endif
- b generic_secondary_common_init
-
/*
* On pSeries and most other platforms, secondary processors spin
* in the following code.
@@ -385,7 +368,6 @@ _GLOBAL(generic_secondary_smp_init)
20:
#endif
-generic_secondary_common_init:
/* Set up a paca value for this processor. Since we have the
* physical cpu id in r24, we need to search the pacas to find
* which logical id maps to our physical one.
--
2.25.1
