* [PATCH] soc: ixp4xx/qmgr: Make use of the helper function devm_platform_ioremap_resource()
From: Cai Huoqing @ 2021-09-08 7:11 UTC (permalink / raw)
To: caihuoqing
Cc: Nishanth Menon, Neil Armstrong, linux-kernel, linux-tegra,
Thierry Reding, Rafał Miłecki, Jerome Brunet,
Florian Fainelli, Kevin Hilman, Jernej Skrabec, Jonathan Hunter,
Chen-Yu Tsai, bcm-kernel-feedback-list, linux-sunxi, linux-pm,
Martin Blumenstingl, Maxime Ripard, Krzysztof Halasa,
Santosh Shilimkar, Matthias Brugger, linux-amlogic,
linux-arm-kernel, linux-mips, Li Yang, linux-mediatek,
linuxppc-dev
In-Reply-To: <20210908071123.348-1-caihuoqing@baidu.com>
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/soc/ixp4xx/ixp4xx-qmgr.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/soc/ixp4xx/ixp4xx-qmgr.c b/drivers/soc/ixp4xx/ixp4xx-qmgr.c
index 9154c7029b05..72b5a10e3104 100644
--- a/drivers/soc/ixp4xx/ixp4xx-qmgr.c
+++ b/drivers/soc/ixp4xx/ixp4xx-qmgr.c
@@ -377,13 +377,9 @@ static int ixp4xx_qmgr_probe(struct platform_device *pdev)
int i, err;
irq_handler_t handler1, handler2;
struct device *dev = &pdev->dev;
- struct resource *res;
int irq1, irq2;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
- qmgr_regs = devm_ioremap_resource(dev, res);
+ qmgr_regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(qmgr_regs))
return PTR_ERR(qmgr_regs);
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] soc: bcm: bcm-pmb: Make use of the helper function devm_platform_ioremap_resource()
From: Cai Huoqing @ 2021-09-08 7:11 UTC (permalink / raw)
To: caihuoqing
Cc: Nishanth Menon, Neil Armstrong, linux-kernel, linux-tegra,
Thierry Reding, Rafał Miłecki, Jerome Brunet,
Florian Fainelli, Kevin Hilman, Jernej Skrabec, Jonathan Hunter,
Chen-Yu Tsai, bcm-kernel-feedback-list, linux-sunxi, linux-pm,
Martin Blumenstingl, Maxime Ripard, Krzysztof Halasa,
Santosh Shilimkar, Matthias Brugger, linux-amlogic,
linux-arm-kernel, linux-mips, Li Yang, linux-mediatek,
linuxppc-dev
In-Reply-To: <20210908071123.348-1-caihuoqing@baidu.com>
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/soc/bcm/bcm63xx/bcm-pmb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/soc/bcm/bcm63xx/bcm-pmb.c b/drivers/soc/bcm/bcm63xx/bcm-pmb.c
index 774465c119be..7bbe46ea5f94 100644
--- a/drivers/soc/bcm/bcm63xx/bcm-pmb.c
+++ b/drivers/soc/bcm/bcm63xx/bcm-pmb.c
@@ -276,7 +276,6 @@ static int bcm_pmb_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
const struct bcm_pmb_pd_data *table;
const struct bcm_pmb_pd_data *e;
- struct resource *res;
struct bcm_pmb *pmb;
int max_id;
int err;
@@ -287,8 +286,7 @@ static int bcm_pmb_probe(struct platform_device *pdev)
pmb->dev = dev;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- pmb->base = devm_ioremap_resource(&pdev->dev, res);
+ pmb->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(pmb->base))
return PTR_ERR(pmb->base);
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] soc: amlogic: canvas: Make use of the helper function devm_platform_ioremap_resource()
From: Cai Huoqing @ 2021-09-08 7:11 UTC (permalink / raw)
To: caihuoqing
Cc: Nishanth Menon, Neil Armstrong, linux-kernel, linux-tegra,
Thierry Reding, Rafał Miłecki, Jerome Brunet,
Florian Fainelli, Kevin Hilman, Jernej Skrabec, Jonathan Hunter,
Chen-Yu Tsai, bcm-kernel-feedback-list, linux-sunxi, linux-pm,
Martin Blumenstingl, Maxime Ripard, Krzysztof Halasa,
Santosh Shilimkar, Matthias Brugger, linux-amlogic,
linux-arm-kernel, linux-mips, Li Yang, linux-mediatek,
linuxppc-dev
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/soc/amlogic/meson-canvas.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/soc/amlogic/meson-canvas.c b/drivers/soc/amlogic/meson-canvas.c
index d0329ad170d1..383b0cfc584e 100644
--- a/drivers/soc/amlogic/meson-canvas.c
+++ b/drivers/soc/amlogic/meson-canvas.c
@@ -168,7 +168,6 @@ EXPORT_SYMBOL_GPL(meson_canvas_free);
static int meson_canvas_probe(struct platform_device *pdev)
{
- struct resource *res;
struct meson_canvas *canvas;
struct device *dev = &pdev->dev;
@@ -176,8 +175,7 @@ static int meson_canvas_probe(struct platform_device *pdev)
if (!canvas)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- canvas->reg_base = devm_ioremap_resource(dev, res);
+ canvas->reg_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(canvas->reg_base))
return PTR_ERR(canvas->reg_base);
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] soc: fsl: guts: Make use of the helper function devm_platform_ioremap_resource()
From: Cai Huoqing @ 2021-09-08 7:11 UTC (permalink / raw)
To: caihuoqing
Cc: Nishanth Menon, Neil Armstrong, linux-kernel, linux-tegra,
Thierry Reding, Rafał Miłecki, Jerome Brunet,
Florian Fainelli, Kevin Hilman, Jernej Skrabec, Jonathan Hunter,
Chen-Yu Tsai, bcm-kernel-feedback-list, linux-sunxi, linux-pm,
Martin Blumenstingl, Maxime Ripard, Krzysztof Halasa,
Santosh Shilimkar, Matthias Brugger, linux-amlogic,
linux-arm-kernel, linux-mips, Li Yang, linux-mediatek,
linuxppc-dev
In-Reply-To: <20210908071123.348-1-caihuoqing@baidu.com>
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/soc/fsl/guts.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index d5e9a5f2c087..072473a16f4d 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -140,7 +140,6 @@ static int fsl_guts_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct device *dev = &pdev->dev;
- struct resource *res;
const struct fsl_soc_die_attr *soc_die;
const char *machine;
u32 svr;
@@ -152,8 +151,7 @@ static int fsl_guts_probe(struct platform_device *pdev)
guts->little_endian = of_property_read_bool(np, "little-endian");
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- guts->regs = devm_ioremap_resource(dev, res);
+ guts->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(guts->regs))
return PTR_ERR(guts->regs);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 1/3] perf: Add macros to specify onchip L2/L3 accesses
From: Michael Ellerman @ 2021-09-08 7:17 UTC (permalink / raw)
To: Kajol Jain, linuxppc-dev, linux-kernel, peterz, mingo, acme,
jolsa, namhyung, linux-perf-users, ak
Cc: mark.rutland, songliubraving, atrajeev, daniel, rnsastry,
alexander.shishkin, kjain, ast, yao.jin, maddy, paulus, kan.liang
In-Reply-To: <20210904064932.307610-1-kjain@linux.ibm.com>
Kajol Jain <kjain@linux.ibm.com> writes:
> Add couple of new macros to represent onchip L2 and onchip L3 accesses.
It would be "on chip". But I think this needs much more explanation,
this is a generic header so these definitions need to make sense, and
have an understood meaning, across all architectures.
I think most people are going to read "on chip" as differentiating
between an L2/L3 that is "on chip" vs "off chip".
But the case you're trying to express is "another core's L2/L3 on the
same chip as the CPU", vs "the current CPU's L2/L3".
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index f92880a15645..030b3e990ac3 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -1265,7 +1265,9 @@ union perf_mem_data_src {
> #define PERF_MEM_LVLNUM_L2 0x02 /* L2 */
> #define PERF_MEM_LVLNUM_L3 0x03 /* L3 */
> #define PERF_MEM_LVLNUM_L4 0x04 /* L4 */
> -/* 5-0xa available */
> +#define PERF_MEM_LVLNUM_OC_L2 0x05 /* On Chip L2 */
> +#define PERF_MEM_LVLNUM_OC_L3 0x06 /* On Chip L3 */
The obvious use for 5 is for "L5" and so on.
I'm not sure adding new levels is the best idea, because these don't fit
neatly into the hierarchy, they are off to the side.
I wonder if we should use the remote field.
ie. for another core's L2 we set:
mem_lvl = PERF_MEM_LVL_L2
mem_remote = 1
Which would mean "remote L2", but not remote enough to be
lvl = PERF_MEM_LVL_REM_CCE1.
It would be printed by the existing tools/perf code as "Remote L2", vs
"Remote cache (1 hop)", which seems OK.
ie. we'd be able to express:
Current core's L2: LVL_L2
Other core's L2: LVL_L2 | REMOTE
Other chip's L2: LVL_REM_CCE1 | REMOTE
And similarly for L3.
I think that makes sense? Unless people think remote should be reserved
to mean on another chip, though we already have REM_CCE1 for that.
cheers
^ permalink raw reply
* [PATCH 2/2] soc: fsl: rcpm: Make use of the helper function devm_platform_ioremap_resource()
From: Cai Huoqing @ 2021-09-08 7:16 UTC (permalink / raw)
To: caihuoqing; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel, Li Yang
In-Reply-To: <20210908071631.660-1-caihuoqing@baidu.com>
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/soc/fsl/rcpm.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index 90d3f4060b0c..3d0cae30c769 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -146,7 +146,6 @@ static const struct dev_pm_ops rcpm_pm_ops = {
static int rcpm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct resource *r;
struct rcpm *rcpm;
int ret;
@@ -154,11 +153,7 @@ static int rcpm_probe(struct platform_device *pdev)
if (!rcpm)
return -ENOMEM;
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r)
- return -ENODEV;
-
- rcpm->ippdexpcr_base = devm_ioremap_resource(&pdev->dev, r);
+ rcpm->ippdexpcr_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(rcpm->ippdexpcr_base)) {
ret = PTR_ERR(rcpm->ippdexpcr_base);
return ret;
--
2.25.1
^ permalink raw reply related
* [PATCH 1/2] soc: fsl: guts: Make use of the helper function devm_platform_ioremap_resource()
From: Cai Huoqing @ 2021-09-08 7:16 UTC (permalink / raw)
To: caihuoqing; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel, Li Yang
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/soc/fsl/guts.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index d5e9a5f2c087..072473a16f4d 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -140,7 +140,6 @@ static int fsl_guts_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct device *dev = &pdev->dev;
- struct resource *res;
const struct fsl_soc_die_attr *soc_die;
const char *machine;
u32 svr;
@@ -152,8 +151,7 @@ static int fsl_guts_probe(struct platform_device *pdev)
guts->little_endian = of_property_read_bool(np, "little-endian");
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- guts->regs = devm_ioremap_resource(dev, res);
+ guts->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(guts->regs))
return PTR_ERR(guts->regs);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] powerpc/mce: Fix access error in mce handler
From: Ganesh @ 2021-09-08 6:49 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: mahesh, npiggin
In-Reply-To: <87mtonmxp6.fsf@mpe.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 5679 bytes --]
On 9/8/21 11:10 AM, Michael Ellerman wrote:
> Ganesh <ganeshgr@linux.ibm.com> writes:
>> On 9/6/21 6:03 PM, Michael Ellerman wrote:
>>
>>> Ganesh Goudar <ganeshgr@linux.ibm.com> writes
>>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>>> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
>>>> CPU: 5 PID: 1883 Comm: insmod Tainted: G OE 5.14.0-mce+ #137
>>>> NIP: c000000000735d60 LR: c000000000318640 CTR: 0000000000000000
>>>> REGS: c00000001ebff9a0 TRAP: 0300 Tainted: G OE (5.14.0-mce+)
>>>> MSR: 8000000000001003 <SF,ME,RI,LE> CR: 28008228 XER: 00000001
>>>> CFAR: c00000000031863c DAR: c00000027fa8fe08 DSISR: 40000000 IRQMASK: 0
>>>> GPR00: c0000000003186d0 c00000001ebffc40 c000000001b0df00 c0000000016337e8
>>>> GPR04: c0000000016337e8 c00000027fa8fe08 0000000000000023 c0000000016337f0
>>>> GPR08: 0000000000000023 c0000000012ffe08 0000000000000000 c008000001460240
>>>> GPR12: 0000000000000000 c00000001ec9a900 c00000002ac4bd00 0000000000000000
>>>> GPR16: 00000000000005a0 c0080000006b0000 c0080000006b05a0 c000000000ff3068
>>>> GPR20: c00000002ac4bbc0 0000000000000001 c00000002ac4bbc0 c008000001490298
>>>> GPR24: c008000001490108 c000000001636198 c008000001470090 c008000001470058
>>>> GPR28: 0000000000000510 c008000001000000 c008000008000019 0000000000000019
>>>> NIP [c000000000735d60] llist_add_batch+0x0/0x40
>>>> LR [c000000000318640] __irq_work_queue_local+0x70/0xc0
>>>> Call Trace:
>>>> [c00000001ebffc40] [c00000001ebffc0c] 0xc00000001ebffc0c (unreliable)
>>>> [c00000001ebffc60] [c0000000003186d0] irq_work_queue+0x40/0x70
>>>> [c00000001ebffc80] [c00000000004425c] machine_check_queue_event+0xbc/0xd0
>>>> [c00000001ebffcf0] [c00000000000838c] machine_check_early_common+0x16c/0x1f4
>>>>
>>>> Fixes: 74c3354bc1d89 ("powerpc/pseries/mce: restore msr before returning from handler")
>>> Please explain in more detail why that commit caused this breakage.
>> After enabling translation in mce_handle_error() we used to leave it enabled to avoid
>> crashing here, but now with this commit we are restoring the MSR to disable translation.
> Are you sure we left the MMU enabled to avoid crashing there, or we just
> left it enabled by accident?
No, I think we left it enabled intentionally, I mentioned about leaving it enabled
in my comment and commit message of a95a0a1654 "powerpc/pseries: Fix MCE handling on pseries".
>
> But yeah, previously the MMU was enabled when we got here whereas now
> it's not, because of that change.
>
>> Missed to mention it in commit log, I will add it.
> Thanks.
>
>>>> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
>>>> index 47a683cd00d2..9d1e39d42e3e 100644
>>>> --- a/arch/powerpc/kernel/mce.c
>>>> +++ b/arch/powerpc/kernel/mce.c
>>>> @@ -249,6 +249,7 @@ void machine_check_queue_event(void)
>>>> {
>>>> int index;
>>>> struct machine_check_event evt;
>>>> + unsigned long msr;
>>>>
>>>> if (!get_mce_event(&evt, MCE_EVENT_RELEASE))
>>>> return;
>>>> @@ -262,8 +263,19 @@ void machine_check_queue_event(void)
>>>> memcpy(&local_paca->mce_info->mce_event_queue[index],
>>>> &evt, sizeof(evt));
>>>>
>>>> - /* Queue irq work to process this event later. */
>>>> - irq_work_queue(&mce_event_process_work);
>>>> + /* Queue irq work to process this event later. Before
>>>> + * queuing the work enable translation for non radix LPAR,
>>>> + * as irq_work_queue may try to access memory outside RMO
>>>> + * region.
>>>> + */
>>>> + if (!radix_enabled() && firmware_has_feature(FW_FEATURE_LPAR)) {
>>>> + msr = mfmsr();
>>>> + mtmsr(msr | MSR_IR | MSR_DR);
>>>> + irq_work_queue(&mce_event_process_work);
>>>> + mtmsr(msr);
>>>> + } else {
>>>> + irq_work_queue(&mce_event_process_work);
>>>> + }
>>>> }
>>> We already went to virtual mode and queued (different) irq work in
>>> arch/powerpc/platforms/pseries/ras.c:mce_handle_error()
>>>
>>> We also called save_mce_event() which also might have queued irq work,
>>> via machine_check_ue_event().
>>>
>>> So it really feels like something about the design is wrong if we have
>>> to go to virtual mode again and queue more irq work here.
>>>
>>> I guess we can probably merge this as a backportable fix, doing anything
>>> else would be a bigger change.
>> I agree.
>>
>>> Looking at ras.c there's the comment:
>>>
>>> * Enable translation as we will be accessing per-cpu variables
>>> * in save_mce_event() which may fall outside RMO region, also
>>>
>>> But AFAICS it's only irq_work_queue() that touches anything percpu?
>> Yeah, we left the comment unchanged after doing some modifications around it,
>> It needs to be updated, ill send a separate patch for it.
> Thanks.
>
> I see some other comments that look out of date, ie. the one above
> machine_check_process_queued_event() mentions syscall exit, which is no
> longer true.
ill take care of it.
>
> There's also comments in pseries/ras.c about fwnmi_release_errinfo()
> crashing in real mode, but we call it in real mode now so that must be
> fixed?
Yes, it is fixed now.
>
>>> So maybe we should just not be using irq_work_queue(). It's a pretty
>>> thin wrapper around set_dec(1), perhaps we just need to hand-roll some
>>> real-mode friendly way of doing that.
>> You mean, have separate queue and run the work from timer handler?
> Yeah something like that.
>
> We don't even need a queue, we already have local_paca->mce_info->mce_queue_count.
>
> So it could just be:
>
> if (local_paca->mce_info->mce_queue_count)
> machine_check_process_queued_event();
>
> Though it would need a wrapper because local_paca only exists for 64-bit.
Thanks, ill look into it.
>
> cheers
[-- Attachment #2: Type: text/html, Size: 7804 bytes --]
^ permalink raw reply
* Re: [PATCH kernel v2] KVM: PPC: Merge powerpc's debugfs entry content into generic entry
From: Alexey Kardashevskiy @ 2021-09-08 6:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paolo Bonzini, Fabiano Rosas, kvm-ppc, kvm
In-Reply-To: <872d75a4-08e2-f597-0bee-6be9fdce0ac1@ozlabs.ru>
[hopefulle fixed my thunderbird now]
Huh, not sure anymore after reading d56f5136b0102 "KVM: let
kvm_destroy_vm_debugfs clean up vCPU debugfs directories" which remove
debugfs_dentry from vcpu. Paolo?
On 05/09/2021 12:27, Alexey Kardashevskiy wrote:
> Please ignore this one, v3 is coming.
>
> After I posted this, I suddenly realized that the vcpu debugfs entry
> remain until the VM exists and this does not handle vcpu
> hotunplug+hotplug (the ppc book3e did handle this). Thanks,
>
>
> On 04/09/2021 23:35, Alexey Kardashevskiy wrote:
>> At the moment the generic KVM code creates an "%pid-%fd" entry per a KVM
>> instance; and the PPC HV KVM creates its own at "vm%pid". The Book3E KVM
>> creates its own entry for timings.
>>
>> The problems with the PPC entries are:
>> 1. they do not allow multiple VMs in the same process (which is extremely
>> rare case mostly used by syzkaller fuzzer);
>> 2. prone to race bugs like the generic KVM code had fixed in
>> commit 85cd39af14f4 ("KVM: Do not leak memory for duplicate debugfs
>> directories").
>>
>> This defines kvm_arch_create_kvm_debugfs() similar to one for vcpus.
>>
>> This defines 2 hooks in kvmppc_ops for allowing specific KVM
>> implementations to add necessary entries. This defines handlers
>> for HV KVM and defines the Book3E debugfs vcpu helper as a handler.
>>
>> This makes use of already existing kvm_arch_create_vcpu_debugfs
>> on PPC.
>>
>> This removes no more used debugfs_dir pointers from PPC kvm_arch structs.
>>
>> Suggested-by: Fabiano Rosas <farosas@linux.ibm.com>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v2:
>> * handled powerpc-booke
>> * s/kvm/vm/ in arch hooks
>> ---
>> arch/powerpc/include/asm/kvm_host.h | 7 +++---
>> arch/powerpc/include/asm/kvm_ppc.h | 2 ++
>> arch/powerpc/kvm/timing.h | 7 +++---
>> include/linux/kvm_host.h | 3 +++
>> arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
>> arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
>> arch/powerpc/kvm/book3s_hv.c | 30 +++++++++-----------------
>> arch/powerpc/kvm/e500.c | 1 +
>> arch/powerpc/kvm/e500mc.c | 1 +
>> arch/powerpc/kvm/powerpc.c | 15 ++++++++++---
>> arch/powerpc/kvm/timing.c | 20 ++++-------------
>> virt/kvm/kvm_main.c | 3 +++
>> 12 files changed, 44 insertions(+), 49 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
>> index 2bcac6da0a4b..f29b66cc2163 100644
>> --- a/arch/powerpc/include/asm/kvm_host.h
>> +++ b/arch/powerpc/include/asm/kvm_host.h
>> @@ -296,7 +296,6 @@ struct kvm_arch {
>> bool dawr1_enabled;
>> pgd_t *pgtable;
>> u64 process_table;
>> - struct dentry *debugfs_dir;
>> struct kvm_resize_hpt *resize_hpt; /* protected by kvm->lock */
>> #endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
>> #ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
>> @@ -672,7 +671,6 @@ struct kvm_vcpu_arch {
>> u64 timing_min_duration[__NUMBER_OF_KVM_EXIT_TYPES];
>> u64 timing_max_duration[__NUMBER_OF_KVM_EXIT_TYPES];
>> u64 timing_last_exit;
>> - struct dentry *debugfs_exit_timing;
>> #endif
>>
>> #ifdef CONFIG_PPC_BOOK3S
>> @@ -828,8 +826,6 @@ struct kvm_vcpu_arch {
>> struct kvmhv_tb_accumulator rm_exit; /* real-mode exit code */
>> struct kvmhv_tb_accumulator guest_time; /* guest execution */
>> struct kvmhv_tb_accumulator cede_time; /* time napping inside guest */
>> -
>> - struct dentry *debugfs_dir;
>> #endif /* CONFIG_KVM_BOOK3S_HV_EXIT_TIMING */
>> };
>>
>> @@ -868,4 +864,7 @@ static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {}
>> static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
>> static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>>
>> +#define __KVM_HAVE_ARCH_VCPU_DEBUGFS
>> +#define __KVM_HAVE_ARCH_KVM_DEBUGFS
>> +
>> #endif /* __POWERPC_KVM_HOST_H__ */
>> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
>> index 6355a6980ccf..fd841e844b90 100644
>> --- a/arch/powerpc/include/asm/kvm_ppc.h
>> +++ b/arch/powerpc/include/asm/kvm_ppc.h
>> @@ -316,6 +316,8 @@ struct kvmppc_ops {
>> int (*svm_off)(struct kvm *kvm);
>> int (*enable_dawr1)(struct kvm *kvm);
>> bool (*hash_v3_possible)(void);
>> + void (*create_vm_debugfs)(struct kvm *kvm);
>> + void (*create_vcpu_debugfs)(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry);
>> };
>>
>> extern struct kvmppc_ops *kvmppc_hv_ops;
>> diff --git a/arch/powerpc/kvm/timing.h b/arch/powerpc/kvm/timing.h
>> index feef7885ba82..36f7c201c6f1 100644
>> --- a/arch/powerpc/kvm/timing.h
>> +++ b/arch/powerpc/kvm/timing.h
>> @@ -14,8 +14,8 @@
>> #ifdef CONFIG_KVM_EXIT_TIMING
>> void kvmppc_init_timing_stats(struct kvm_vcpu *vcpu);
>> void kvmppc_update_timing_stats(struct kvm_vcpu *vcpu);
>> -void kvmppc_create_vcpu_debugfs(struct kvm_vcpu *vcpu, unsigned int id);
>> -void kvmppc_remove_vcpu_debugfs(struct kvm_vcpu *vcpu);
>> +void kvmppc_create_vcpu_debugfs(struct kvm_vcpu *vcpu,
>> + struct dentry *debugfs_dentry);
>>
>> static inline void kvmppc_set_exit_type(struct kvm_vcpu *vcpu, int type)
>> {
>> @@ -27,8 +27,7 @@ static inline void kvmppc_set_exit_type(struct kvm_vcpu *vcpu, int type)
>> static inline void kvmppc_init_timing_stats(struct kvm_vcpu *vcpu) {}
>> static inline void kvmppc_update_timing_stats(struct kvm_vcpu *vcpu) {}
>> static inline void kvmppc_create_vcpu_debugfs(struct kvm_vcpu *vcpu,
>> - unsigned int id) {}
>> -static inline void kvmppc_remove_vcpu_debugfs(struct kvm_vcpu *vcpu) {}
>> + struct dentry *debugfs_dentry) {}
>> static inline void kvmppc_set_exit_type(struct kvm_vcpu *vcpu, int type) {}
>> #endif /* CONFIG_KVM_EXIT_TIMING */
>>
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index ae7735b490b4..4f22b1201a0d 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -1021,6 +1021,9 @@ int kvm_arch_pm_notifier(struct kvm *kvm, unsigned long state);
>> #ifdef __KVM_HAVE_ARCH_VCPU_DEBUGFS
>> void kvm_arch_create_vcpu_debugfs(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry);
>> #endif
>> +#ifdef __KVM_HAVE_ARCH_KVM_DEBUGFS
>> +void kvm_arch_create_vm_debugfs(struct kvm *kvm);
>> +#endif
>>
>> int kvm_arch_hardware_enable(void);
>> void kvm_arch_hardware_disable(void);
>> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
>> index c63e263312a4..33dae253a0ac 100644
>> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
>> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
>> @@ -2112,7 +2112,7 @@ static const struct file_operations debugfs_htab_fops = {
>>
>> void kvmppc_mmu_debugfs_init(struct kvm *kvm)
>> {
>> - debugfs_create_file("htab", 0400, kvm->arch.debugfs_dir, kvm,
>> + debugfs_create_file("htab", 0400, kvm->debugfs_dentry, kvm,
>> &debugfs_htab_fops);
>> }
>>
>> diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
>> index c5508744e14c..f4e083c20872 100644
>> --- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
>> +++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
>> @@ -1452,7 +1452,7 @@ static const struct file_operations debugfs_radix_fops = {
>>
>> void kvmhv_radix_debugfs_init(struct kvm *kvm)
>> {
>> - debugfs_create_file("radix", 0400, kvm->arch.debugfs_dir, kvm,
>> + debugfs_create_file("radix", 0400, kvm->debugfs_dentry, kvm,
>> &debugfs_radix_fops);
>> }
>>
>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>> index c8f12b056968..046df9e0d462 100644
>> --- a/arch/powerpc/kvm/book3s_hv.c
>> +++ b/arch/powerpc/kvm/book3s_hv.c
>> @@ -2771,19 +2771,14 @@ static const struct file_operations debugfs_timings_ops = {
>> };
>>
>> /* Create a debugfs directory for the vcpu */
>> -static void debugfs_vcpu_init(struct kvm_vcpu *vcpu, unsigned int id)
>> +static void kvmppc_arch_create_vcpu_debugfs_hv(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry)
>> {
>> - char buf[16];
>> - struct kvm *kvm = vcpu->kvm;
>> -
>> - snprintf(buf, sizeof(buf), "vcpu%u", id);
>> - vcpu->arch.debugfs_dir = debugfs_create_dir(buf, kvm->arch.debugfs_dir);
>> - debugfs_create_file("timings", 0444, vcpu->arch.debugfs_dir, vcpu,
>> + debugfs_create_file("timings", 0444, debugfs_dentry, vcpu,
>> &debugfs_timings_ops);
>> }
>>
>> #else /* CONFIG_KVM_BOOK3S_HV_EXIT_TIMING */
>> -static void debugfs_vcpu_init(struct kvm_vcpu *vcpu, unsigned int id)
>> +static void kvmppc_arch_create_vcpu_debugfs_hv(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry)
>> {
>> }
>> #endif /* CONFIG_KVM_BOOK3S_HV_EXIT_TIMING */
>> @@ -2907,8 +2902,6 @@ static int kvmppc_core_vcpu_create_hv(struct kvm_vcpu *vcpu)
>> vcpu->arch.cpu_type = KVM_CPU_3S_64;
>> kvmppc_sanity_check(vcpu);
>>
>> - debugfs_vcpu_init(vcpu, id);
>> -
>> return 0;
>> }
>>
>> @@ -5186,7 +5179,6 @@ void kvmppc_free_host_rm_ops(void)
>> static int kvmppc_core_init_vm_hv(struct kvm *kvm)
>> {
>> unsigned long lpcr, lpid;
>> - char buf[32];
>> int ret;
>>
>> mutex_init(&kvm->arch.uvmem_lock);
>> @@ -5319,16 +5311,14 @@ static int kvmppc_core_init_vm_hv(struct kvm *kvm)
>> kvm->arch.smt_mode = 1;
>> kvm->arch.emul_smt_mode = 1;
>>
>> - /*
>> - * Create a debugfs directory for the VM
>> - */
>> - snprintf(buf, sizeof(buf), "vm%d", current->pid);
>> - kvm->arch.debugfs_dir = debugfs_create_dir(buf, kvm_debugfs_dir);
>> + return 0;
>> +}
>> +
>> +static void kvmppc_arch_create_vm_debugfs_hv(struct kvm *kvm)
>> +{
>> kvmppc_mmu_debugfs_init(kvm);
>> if (radix_enabled())
>> kvmhv_radix_debugfs_init(kvm);
>> -
>> - return 0;
>> }
>>
>> static void kvmppc_free_vcores(struct kvm *kvm)
>> @@ -5342,8 +5332,6 @@ static void kvmppc_free_vcores(struct kvm *kvm)
>>
>> static void kvmppc_core_destroy_vm_hv(struct kvm *kvm)
>> {
>> - debugfs_remove_recursive(kvm->arch.debugfs_dir);
>> -
>> if (!cpu_has_feature(CPU_FTR_ARCH_300))
>> kvm_hv_vm_deactivated();
>>
>> @@ -5996,6 +5984,8 @@ static struct kvmppc_ops kvm_ops_hv = {
>> .svm_off = kvmhv_svm_off,
>> .enable_dawr1 = kvmhv_enable_dawr1,
>> .hash_v3_possible = kvmppc_hash_v3_possible,
>> + .create_vcpu_debugfs = kvmppc_arch_create_vcpu_debugfs_hv,
>> + .create_vm_debugfs = kvmppc_arch_create_vm_debugfs_hv,
>> };
>>
>> static int kvm_init_subcore_bitmap(void)
>> diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
>> index 7e8b69015d20..d82e70c3e0a9 100644
>> --- a/arch/powerpc/kvm/e500.c
>> +++ b/arch/powerpc/kvm/e500.c
>> @@ -495,6 +495,7 @@ static struct kvmppc_ops kvm_ops_e500 = {
>> .emulate_op = kvmppc_core_emulate_op_e500,
>> .emulate_mtspr = kvmppc_core_emulate_mtspr_e500,
>> .emulate_mfspr = kvmppc_core_emulate_mfspr_e500,
>> + .create_vcpu_debugfs = kvmppc_create_vcpu_debugfs,
>> };
>>
>> static int __init kvmppc_e500_init(void)
>> diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
>> index 1c189b5aadcc..45eacd949f4b 100644
>> --- a/arch/powerpc/kvm/e500mc.c
>> +++ b/arch/powerpc/kvm/e500mc.c
>> @@ -381,6 +381,7 @@ static struct kvmppc_ops kvm_ops_e500mc = {
>> .emulate_op = kvmppc_core_emulate_op_e500,
>> .emulate_mtspr = kvmppc_core_emulate_mtspr_e500,
>> .emulate_mfspr = kvmppc_core_emulate_mfspr_e500,
>> + .create_vcpu_debugfs = kvmppc_create_vcpu_debugfs,
>> };
>>
>> static int __init kvmppc_e500mc_init(void)
>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> index c248d6d8b9e3..c895521ac6e9 100644
>> --- a/arch/powerpc/kvm/powerpc.c
>> +++ b/arch/powerpc/kvm/powerpc.c
>> @@ -763,7 +763,6 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
>> goto out_vcpu_uninit;
>>
>> vcpu->arch.waitp = &vcpu->wait;
>> - kvmppc_create_vcpu_debugfs(vcpu, vcpu->vcpu_id);
>> return 0;
>>
>> out_vcpu_uninit:
>> @@ -780,8 +779,6 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
>> /* Make sure we're not using the vcpu anymore */
>> hrtimer_cancel(&vcpu->arch.dec_timer);
>>
>> - kvmppc_remove_vcpu_debugfs(vcpu);
>> -
>> switch (vcpu->arch.irq_type) {
>> case KVMPPC_IRQ_MPIC:
>> kvmppc_mpic_disconnect_vcpu(vcpu->arch.mpic, vcpu);
>> @@ -2505,3 +2502,15 @@ int kvm_arch_init(void *opaque)
>> }
>>
>> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_ppc_instr);
>> +
>> +void kvm_arch_create_vcpu_debugfs(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry)
>> +{
>> + if (vcpu->kvm->arch.kvm_ops->create_vcpu_debugfs)
>> + vcpu->kvm->arch.kvm_ops->create_vcpu_debugfs(vcpu, debugfs_dentry);
>> +}
>> +
>> +void kvm_arch_create_vm_debugfs(struct kvm *kvm)
>> +{
>> + if (kvm->arch.kvm_ops->create_vm_debugfs)
>> + kvm->arch.kvm_ops->create_vm_debugfs(kvm);
>> +}
>> diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c
>> index ba56a5cbba97..e1c17afc714d 100644
>> --- a/arch/powerpc/kvm/timing.c
>> +++ b/arch/powerpc/kvm/timing.c
>> @@ -204,21 +204,9 @@ static const struct file_operations kvmppc_exit_timing_fops = {
>> .release = single_release,
>> };
>>
>> -void kvmppc_create_vcpu_debugfs(struct kvm_vcpu *vcpu, unsigned int id)
>> +void kvmppc_create_vcpu_debugfs(struct kvm_vcpu *vcpu,
>> + struct dentry *debugfs_dentry)
>> {
>> - static char dbg_fname[50];
>> - struct dentry *debugfs_file;
>> -
>> - snprintf(dbg_fname, sizeof(dbg_fname), "vm%u_vcpu%u_timing",
>> - current->pid, id);
>> - debugfs_file = debugfs_create_file(dbg_fname, 0666, kvm_debugfs_dir,
>> - vcpu, &kvmppc_exit_timing_fops);
>> -
>> - vcpu->arch.debugfs_exit_timing = debugfs_file;
>> -}
>> -
>> -void kvmppc_remove_vcpu_debugfs(struct kvm_vcpu *vcpu)
>> -{
>> - debugfs_remove(vcpu->arch.debugfs_exit_timing);
>> - vcpu->arch.debugfs_exit_timing = NULL;
>> + debugfs_create_file("timing", 0666, debugfs_dentry,
>> + vcpu, &kvmppc_exit_timing_fops);
>> }
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index b50dbe269f4b..85b2550e18e7 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -954,6 +954,9 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd)
>> kvm->debugfs_dentry, stat_data,
>> &stat_fops_per_vm);
>> }
>> +#ifdef __KVM_HAVE_ARCH_KVM_DEBUGFS
>> + kvm_arch_create_vm_debugfs(kvm);
>> +#endif
>> return 0;
>> }
>>
>>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH] powerpc/mce: Fix access error in mce handler
From: Michael Ellerman @ 2021-09-08 5:40 UTC (permalink / raw)
To: Ganesh, linuxppc-dev; +Cc: mahesh, npiggin
In-Reply-To: <f14cb57a-5ae0-f867-1e18-004f34a3b320@linux.ibm.com>
Ganesh <ganeshgr@linux.ibm.com> writes:
> On 9/6/21 6:03 PM, Michael Ellerman wrote:
>
>> Ganesh Goudar <ganeshgr@linux.ibm.com> writes:
>>> We queue an irq work for deferred processing of mce event
>>> in realmode mce handler, where translation is disabled.
>>> Queuing of the work may result in accessing memory outside
>>> RMO region, such access needs the translation to be enabled
>>> for an LPAR running with hash mmu else the kernel crashes.
>>>
>>> So enable the translation before queuing the work.
>>>
>>> Without this change following trace is seen on injecting machine
>>> check error in an LPAR running with hash mmu.
>> What type of error are you injecting?
>
> SLB multihit in kernel mode.
>
>>
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
>>> CPU: 5 PID: 1883 Comm: insmod Tainted: G OE 5.14.0-mce+ #137
>>> NIP: c000000000735d60 LR: c000000000318640 CTR: 0000000000000000
>>> REGS: c00000001ebff9a0 TRAP: 0300 Tainted: G OE (5.14.0-mce+)
>>> MSR: 8000000000001003 <SF,ME,RI,LE> CR: 28008228 XER: 00000001
>>> CFAR: c00000000031863c DAR: c00000027fa8fe08 DSISR: 40000000 IRQMASK: 0
>>> GPR00: c0000000003186d0 c00000001ebffc40 c000000001b0df00 c0000000016337e8
>>> GPR04: c0000000016337e8 c00000027fa8fe08 0000000000000023 c0000000016337f0
>>> GPR08: 0000000000000023 c0000000012ffe08 0000000000000000 c008000001460240
>>> GPR12: 0000000000000000 c00000001ec9a900 c00000002ac4bd00 0000000000000000
>>> GPR16: 00000000000005a0 c0080000006b0000 c0080000006b05a0 c000000000ff3068
>>> GPR20: c00000002ac4bbc0 0000000000000001 c00000002ac4bbc0 c008000001490298
>>> GPR24: c008000001490108 c000000001636198 c008000001470090 c008000001470058
>>> GPR28: 0000000000000510 c008000001000000 c008000008000019 0000000000000019
>>> NIP [c000000000735d60] llist_add_batch+0x0/0x40
>>> LR [c000000000318640] __irq_work_queue_local+0x70/0xc0
>>> Call Trace:
>>> [c00000001ebffc40] [c00000001ebffc0c] 0xc00000001ebffc0c (unreliable)
>>> [c00000001ebffc60] [c0000000003186d0] irq_work_queue+0x40/0x70
>>> [c00000001ebffc80] [c00000000004425c] machine_check_queue_event+0xbc/0xd0
>>> [c00000001ebffcf0] [c00000000000838c] machine_check_early_common+0x16c/0x1f4
>>>
>>> Fixes: 74c3354bc1d89 ("powerpc/pseries/mce: restore msr before returning from handler")
>> Please explain in more detail why that commit caused this breakage.
>
> After enabling translation in mce_handle_error() we used to leave it enabled to avoid
> crashing here, but now with this commit we are restoring the MSR to disable translation.
Are you sure we left the MMU enabled to avoid crashing there, or we just
left it enabled by accident?
But yeah, previously the MMU was enabled when we got here whereas now
it's not, because of that change.
> Missed to mention it in commit log, I will add it.
Thanks.
>>> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
>>> index 47a683cd00d2..9d1e39d42e3e 100644
>>> --- a/arch/powerpc/kernel/mce.c
>>> +++ b/arch/powerpc/kernel/mce.c
>>> @@ -249,6 +249,7 @@ void machine_check_queue_event(void)
>>> {
>>> int index;
>>> struct machine_check_event evt;
>>> + unsigned long msr;
>>>
>>> if (!get_mce_event(&evt, MCE_EVENT_RELEASE))
>>> return;
>>> @@ -262,8 +263,19 @@ void machine_check_queue_event(void)
>>> memcpy(&local_paca->mce_info->mce_event_queue[index],
>>> &evt, sizeof(evt));
>>>
>>> - /* Queue irq work to process this event later. */
>>> - irq_work_queue(&mce_event_process_work);
>>> + /* Queue irq work to process this event later. Before
>>> + * queuing the work enable translation for non radix LPAR,
>>> + * as irq_work_queue may try to access memory outside RMO
>>> + * region.
>>> + */
>>> + if (!radix_enabled() && firmware_has_feature(FW_FEATURE_LPAR)) {
>>> + msr = mfmsr();
>>> + mtmsr(msr | MSR_IR | MSR_DR);
>>> + irq_work_queue(&mce_event_process_work);
>>> + mtmsr(msr);
>>> + } else {
>>> + irq_work_queue(&mce_event_process_work);
>>> + }
>>> }
>> We already went to virtual mode and queued (different) irq work in
>> arch/powerpc/platforms/pseries/ras.c:mce_handle_error()
>>
>> We also called save_mce_event() which also might have queued irq work,
>> via machine_check_ue_event().
>>
>> So it really feels like something about the design is wrong if we have
>> to go to virtual mode again and queue more irq work here.
>>
>> I guess we can probably merge this as a backportable fix, doing anything
>> else would be a bigger change.
>
> I agree.
>
>>
>> Looking at ras.c there's the comment:
>>
>> * Enable translation as we will be accessing per-cpu variables
>> * in save_mce_event() which may fall outside RMO region, also
>>
>> But AFAICS it's only irq_work_queue() that touches anything percpu?
>
> Yeah, we left the comment unchanged after doing some modifications around it,
> It needs to be updated, ill send a separate patch for it.
Thanks.
I see some other comments that look out of date, ie. the one above
machine_check_process_queued_event() mentions syscall exit, which is no
longer true.
There's also comments in pseries/ras.c about fwnmi_release_errinfo()
crashing in real mode, but we call it in real mode now so that must be
fixed?
>> So maybe we should just not be using irq_work_queue(). It's a pretty
>> thin wrapper around set_dec(1), perhaps we just need to hand-roll some
>> real-mode friendly way of doing that.
>
> You mean, have separate queue and run the work from timer handler?
Yeah something like that.
We don't even need a queue, we already have local_paca->mce_info->mce_queue_count.
So it could just be:
if (local_paca->mce_info->mce_queue_count)
machine_check_process_queued_event();
Though it would need a wrapper because local_paca only exists for 64-bit.
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/perf: Expose instruction and data address registers as part of extended regs
From: Michael Ellerman @ 2021-09-08 5:17 UTC (permalink / raw)
To: Athira Rajeev, acme, jolsa; +Cc: kjain, maddy, linuxppc-dev, rnsastry
In-Reply-To: <1624200360-1429-2-git-send-email-atrajeev@linux.vnet.ibm.com>
Athira Rajeev <atrajeev@linux.vnet.ibm.com> writes:
> Patch adds support to include Sampled Instruction Address Register
> (SIAR) and Sampled Data Address Register (SDAR) SPRs as part of extended
> registers. Update the definition of PERF_REG_PMU_MASK_300/31 and
> PERF_REG_EXTENDED_MAX to include these SPR's.
>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/uapi/asm/perf_regs.h | 12 +++++++-----
> arch/powerpc/perf/perf_regs.c | 4 ++++
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
...
> diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
> index b931eed..51d31b6 100644
> --- a/arch/powerpc/perf/perf_regs.c
> +++ b/arch/powerpc/perf/perf_regs.c
> @@ -90,7 +90,11 @@ static u64 get_ext_regs_value(int idx)
> return mfspr(SPRN_SIER2);
> case PERF_REG_POWERPC_SIER3:
> return mfspr(SPRN_SIER3);
> + case PERF_REG_POWERPC_SDAR:
> + return mfspr(SPRN_SDAR);
> #endif
> + case PERF_REG_POWERPC_SIAR:
> + return mfspr(SPRN_SIAR);
> default: return 0;
> }
This file is built for all powerpc configs that have PERF_EVENTS. Which
includes CPUs that don't have SDAR or SIAR.
Don't we need checks in perf_reg_value() like we do for SIER?
I guess we already got this wrong when we added the Power10 registers,
SIER2/3 etc.
cheers
^ permalink raw reply
* Re: [RFC PATCH v2] powerpc/papr_scm: Move duplicate definitions to common header files
From: Michael Ellerman @ 2021-09-08 5:02 UTC (permalink / raw)
To: Shivaprasad G Bhat, linuxppc-dev, linux-kernel
Cc: nvdimm, dan.j.williams, vaibhav, sbhat, aneesh.kumar
In-Reply-To: <163092037510.812.12838160593592476913.stgit@82313cf9f602>
Shivaprasad G Bhat <sbhat@linux.ibm.com> writes:
> papr_scm and ndtest share common PDSM payload structs like
> nd_papr_pdsm_health. Presently these structs are duplicated across papr_pdsm.h
> and ndtest.h header files. Since 'ndtest' is essentially arch independent and can
> run on platforms other than PPC64, a way needs to be deviced to avoid redundancy
> and duplication of PDSM structs in future.
>
> So the patch proposes moving the PDSM header from arch/powerpc/include/uapi/ to
> the generic include/uapi/linux directory. Also, there are some #defines common
> between papr_scm and ndtest which are not exported to the user space. So, move
> them to a header file which can be shared across ndtest and papr_scm via newly
> introduced include/linux/papr_scm.h.
>
> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> Suggested-by: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
> ---
> Changelog:
>
> Since v1:
> Link: https://patchwork.kernel.org/project/linux-nvdimm/patch/162505488483.72147.12741153746322191381.stgit@56e104a48989/
> * Removed dependency on this patch for the other patches
>
> MAINTAINERS | 2
> arch/powerpc/include/uapi/asm/papr_pdsm.h | 165 -----------------------------
> arch/powerpc/platforms/pseries/papr_scm.c | 43 --------
> include/linux/papr_scm.h | 48 ++++++++
> include/uapi/linux/papr_pdsm.h | 165 +++++++++++++++++++++++++++++
This doesn't make sense to me.
Anything with papr (or PAPR) in the name is fundamentally powerpc
specific, it doesn't belong in a generic header, or in a generic
location.
What's the actual problem you're trying to solve?
If it's just including papr_scm bits into ndtest.c then that should be
as simple as:
#ifdef __powerpc__
#include <asm/papr_scm.h>
#endif
Shouldn't it?
cheers
^ permalink raw reply
* Re: [PATCH v3] ftrace: Cleanup ftrace_dyn_arch_init()
From: Weizhao Ouyang @ 2021-09-08 3:52 UTC (permalink / raw)
To: LEROY Christophe, Steven Rostedt, Ingo Molnar
Cc: Rich Felker, linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Catalin Marinas, linux-kernel@vger.kernel.org,
James E.J. Bottomley, Guo Ren, H. Peter Anvin,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
Vincent Chen, Will Deacon, linux-s390@vger.kernel.org,
Yoshinori Sato, Helge Deller, x86@kernel.org, Russell King,
linux-csky@vger.kernel.org, Christian Borntraeger, Albert Ou,
Vasily Gorbik, Heiko Carstens, Borislav Petkov, Greentime Hu,
Paul Walmsley, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Michal Simek,
Thomas Bogendoerfer, Nick Hu, linux-parisc@vger.kernel.org,
linux-mips@vger.kernel.org, Palmer Dabbelt, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <MRZP264MB298824D80E6C0ADCB5EA1D9AEDD39@MRZP264MB2988.FRAP264.PROD.OUTLOOK.COM>
Thanks for reply.
On 2021/9/7 23:55, LEROY Christophe wrote:
>
>> -----Message d'origine-----
>> De : Linuxppc-dev <linuxppc-dev-
>> bounces+christophe.leroy=csgroup.eu@lists.ozlabs.org> De la part de Weizhao
>> Ouyang
>>
>> Most of ARCHs use empty ftrace_dyn_arch_init(), introduce a weak common
>> ftrace_dyn_arch_init() to cleanup them.
>>
>> Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
>> Acked-by: Heiko Carstens <hca@linux.ibm.com> (s390)
>> Acked-by: Helge Deller <deller@gmx.de> (parisc)
>>
>> ---
>> Changes in v3:
>> -- fix unrecognized opcode on PowerPC
>>
>> Changes in v2:
>> -- correct CONFIG_DYNAMIC_FTRACE on PowerPC
>> -- add Acked-by tag
>>
>> ---
>> arch/arm/kernel/ftrace.c | 5 -----
>> arch/arm64/kernel/ftrace.c | 5 -----
>> arch/csky/kernel/ftrace.c | 5 -----
>> arch/ia64/kernel/ftrace.c | 6 ------
>> arch/microblaze/kernel/ftrace.c | 5 -----
>> arch/mips/include/asm/ftrace.h | 2 ++
>> arch/nds32/kernel/ftrace.c | 5 -----
>> arch/parisc/kernel/ftrace.c | 5 -----
>> arch/powerpc/include/asm/ftrace.h | 4 ++++
>> arch/riscv/kernel/ftrace.c | 5 -----
>> arch/s390/kernel/ftrace.c | 5 -----
>> arch/sh/kernel/ftrace.c | 5 -----
>> arch/sparc/kernel/ftrace.c | 5 -----
>> arch/x86/kernel/ftrace.c | 5 -----
>> include/linux/ftrace.h | 1 -
>> kernel/trace/ftrace.c | 5 +++++
>> 16 files changed, 11 insertions(+), 62 deletions(-)
>>
>> diff --git a/arch/mips/include/asm/ftrace.h b/arch/mips/include/asm/ftrace.h
>> index b463f2aa5a61..ed013e767390 100644
>> --- a/arch/mips/include/asm/ftrace.h
>> +++ b/arch/mips/include/asm/ftrace.h
>> @@ -76,6 +76,8 @@ do { \
>>
>>
>> #ifdef CONFIG_DYNAMIC_FTRACE
>> +int __init ftrace_dyn_arch_init(void);
>> +
> Why ?
>
>
>> static inline unsigned long ftrace_call_adjust(unsigned long addr)
>> {
>> return addr;
>> diff --git a/arch/powerpc/include/asm/ftrace.h
>> b/arch/powerpc/include/asm/ftrace.h
>> index debe8c4f7062..b05c43f13a4d 100644
>> --- a/arch/powerpc/include/asm/ftrace.h
>> +++ b/arch/powerpc/include/asm/ftrace.h
>> @@ -126,6 +126,10 @@ static inline void this_cpu_enable_ftrace(void) { }
>> static inline void this_cpu_set_ftrace_enabled(u8 ftrace_enabled) { }
>> static inline u8 this_cpu_get_ftrace_enabled(void) { return 1; }
>> #endif /* CONFIG_PPC64 */
>> +
>> +#ifdef CONFIG_DYNAMIC_FTRACE
>> +int __init ftrace_dyn_arch_init(void);
>> +#endif /* CONFIG_DYNAMIC_FTRACE */
> Why ?
>
>> #endif /* !__ASSEMBLY__ */
>>
>> #endif /* _ASM_POWERPC_FTRACE */
>> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
>> index 832e65f06754..f1eca123d89d 100644
>> --- a/include/linux/ftrace.h
>> +++ b/include/linux/ftrace.h
>> @@ -573,7 +573,6 @@ ftrace_set_early_filter(struct ftrace_ops *ops, char
>> *buf, int enable);
>>
>> /* defined in arch */
>> extern int ftrace_ip_converted(unsigned long ip);
>> -extern int ftrace_dyn_arch_init(void);
> Why removing that ?
>
> Have you tried to build kernel/trace/ftrace.o with C=2 ? It will likely tell you that the function is not declared and that it should be static
Yes I missed this check. Under the situation, the function should be static.
> We could eventually consider that in the past, this generic declaration was unrelevant because the definitions where in the arch specific sections.
> Now that you are implementing a generic weak version of this function, it would make sense to have a generic declaration as well.
>
> I really don't see the point in duplicating the declaration of the function in the arch specific headers.
I use declaration in arch specific headers in tend to clarify the arch has implement ftrace_dyn_arch_init().
Anyway, it maybe pointless, a generic declaration is enough. Will update it later.
>> extern void ftrace_replace_code(int enable);
>> extern int ftrace_update_ftrace_func(ftrace_func_t func);
>> extern void ftrace_caller(void);
> Christophe
>
> CS Group - Document Interne
^ permalink raw reply
* Re: [PATCH 0/5] s390/pci: automatic error recovery
From: Oliver O'Halloran @ 2021-09-08 1:37 UTC (permalink / raw)
To: Niklas Schnelle
Cc: linux-s390, Pierre Morel, Matthew Rosato,
Linux Kernel Mailing List, Bjorn Helgaas, Linas Vepstas,
linuxppc-dev
In-Reply-To: <0c9326c943c0e6aa572cc132ee2deb952bf41c7f.camel@linux.ibm.com>
On Tue, Sep 7, 2021 at 10:21 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
>
> On Tue, 2021-09-07 at 10:45 +0200, Niklas Schnelle wrote:
> > On Tue, 2021-09-07 at 12:04 +1000, Oliver O'Halloran wrote:
> > > On Mon, Sep 6, 2021 at 7:49 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > > Patch 3 I already sent separately resulting in the discussion below but without
> > > > a final conclusion.
> > > >
> > > > https://lore.kernel.org/lkml/20210720150145.640727-1-schnelle@linux.ibm.com/
> > > >
> > > > I believe even though there were some doubts about the use of
> > > > pci_dev_is_added() by arch code the existing uses as well as the use in the
> > > > final patch of this series warrant this export.
> > >
> > > The use of pci_dev_is_added() in arch/powerpc was because in the past
> > > pci_bus_add_device() could be called before pci_device_add(). That was
> > > fixed a while ago so It should be safe to remove those calls now.
> >
> > Hmm, ok that confirms Bjorns suspicion and explains how it came to be.
> > I can certainly sent a patch for that. This would then leave only the
> > existing use in s390 which I added because of a dead lock prevention
> > and explained here:
> > https://lore.kernel.org/lkml/87d15d5eead35c9eaa667958d057cf4a81a8bf13.camel@linux.ibm.com/
> >
> > Plus the need to use it in the recovery code of this series. I think in
> > the EEH code the need for a similar check is alleviated by the checks
> > in the beginning of
> > arch/powerpc/kernel/eeh_driver.c:eeh_handle_normal_event() especially
> > eeh_slot_presence_check() which checks presence via the hotplug slot.
> > I guess we could use our own state tracking in a similar way but felt
> > like pci_dev_is_added() is the more logical choice.
The slot check is mainly there to prevent attempts to "recover"
devices that have been surprise removed (i.e NVMe hot-unplug). The
actual recovery process operates off the eeh_pe tree which is frozen
in place when an error is detected. If a pci_dev is added or removed
it's not really a problem since those are only ever looked at when
notifying drivers which is done with the rescan_remove lock held. That
said, I wouldn't really encourage anyone to follow the EEH model since
it's pretty byzantine.
> Looking into this again, I think we actually can't easily track this
> state ourselves outside struct pci_dev. The reason for this is that
> when e.g. arch/s390/pci/pci_sysfs.c:recover_store() removes the struct
> pci_dev and scans it again the new struct pci_dev re-uses the same
> struct zpci_dev because from a platform point of view the PCI device
> was never removed but only disabled and re-enabled. Thus we can only
> distinguish the stale struct pci_dev by looking at things stored in
> struct pci_dev itself.
IMO the real problem is removing and re-adding the pci_dev. I think
it's something that's done largely because the PCI core doesn't really
provide any better mechanism for getting a device back into a
known-good state so it's abused to implement error recovery. This is
something that's always annoyed me since it conflates recovery with
hotplug. After a hot-(un)plug we might have a different device or no
device. In the recovery case we expect to start and end with the same
device. Why not apply the same logic to the pci_dev?
Something I was tinkering with before I left IBM was re-working the
way EEH handles recovering devices that don't have a driver with error
handling callbacks to something like:
1. unbind the driver
2. pci_save_state()
3. do the reset
4. pci_restore_state()
5. re-bind the driver
That would allow keeping the pci_dev around and let me delete a pile
of confusing code which handles binding the eeh_dev to the new
pci_dev. The obvious problem with that approach is the assumption the
device is functional enough to allow saving the config space, but I
don't think that's a deal breaker. We could stash a copy of the device
state before we allow drivers to attach and use that to restore the
device after the reset. The end result would be the same known-good
state that we'd get after a re-scan.
> That said, I think for the recovery case we might be able to drop the
> pci_dev_is_added() and rely on pdev->driver != NULL which we check
> anyway and that should catch any PCI device that was already removed.
Would that work if there was an error on a device without a driver
bound? If you're just trying to stop races between recovery and device
removal then pci_dev_is_added() is probably the right tool for the
job. Trying to substitute it with a proxy seems like a bad idea.
^ permalink raw reply
* Re: [RESEND PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries
From: Dan Williams @ 2021-09-08 1:03 UTC (permalink / raw)
To: Kajol Jain
Cc: Linux NVDIMM, Santosh Sivaraj, maddy, Weiny, Ira, rnsastry,
Peter Zijlstra, Linux Kernel Mailing List, atrajeev,
Aneesh Kumar K.V, Vishal L Verma, Vaibhav Jain, Thomas Gleixner,
linuxppc-dev
In-Reply-To: <20210903050914.273525-5-kjain@linux.ibm.com>
On Thu, Sep 2, 2021 at 10:11 PM Kajol Jain <kjain@linux.ibm.com> wrote:
>
> Details is added for the event, cpumask and format attributes
> in the ABI documentation.
>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
> Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 +++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
> index 95254cec92bf..4d86252448f8 100644
> --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
> +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
> @@ -61,3 +61,34 @@ Description:
> * "CchRHCnt" : Cache Read Hit Count
> * "CchWHCnt" : Cache Write Hit Count
> * "FastWCnt" : Fast Write Count
> +
> +What: /sys/devices/nmemX/format
> +Date: June 2021
> +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
> +Description: (RO) Attribute group to describe the magic bits
> + that go into perf_event_attr.config for a particular pmu.
> + (See ABI/testing/sysfs-bus-event_source-devices-format).
> +
> + Each attribute under this group defines a bit range of the
> + perf_event_attr.config. Supported attribute is listed
> + below::
> +
> + event = "config:0-4" - event ID
> +
> + For example::
> + noopstat = "event=0x1"
> +
> +What: /sys/devices/nmemX/events
That's not a valid sysfs path. Did you mean /sys/bus/nd/devices/nmemX?
> +Date: June 2021
> +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
> +Description: (RO) Attribute group to describe performance monitoring
> + events specific to papr-scm. Each attribute in this group describes
> + a single performance monitoring event supported by this nvdimm pmu.
> + The name of the file is the name of the event.
> + (See ABI/testing/sysfs-bus-event_source-devices-events).
Given these events are in the generic namespace the ABI documentation
should be generic as well. So I think move these entries to
Documentation/ABI/testing/sysfs-bus-nvdimm directly.
You can still mention papr-scm, but I would expect something like:
What: /sys/bus/nd/devices/nmemX/events
Date: September 2021
KernelVersion: 5.16
Contact: Kajol Jain <kjain@linux.ibm.com>
Description:
(RO) Attribute group to describe performance monitoring events
for the nvdimm memory device. Each attribute in this group
describes a single performance monitoring event supported by
this nvdimm pmu. The name of the file is the name of the event.
(See ABI/testing/sysfs-bus-event_source-devices-events). A
listing of the events supported by a given nvdimm provider type
can be found in Documentation/driver-api/nvdimm/$provider, for
example: Documentation/driver-api/nvdimm/papr-scm.
> +
> +What: /sys/devices/nmemX/cpumask
> +Date: June 2021
> +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
> +Description: (RO) This sysfs file exposes the cpumask which is designated to make
> + HCALLs to retrieve nvdimm pmu event counter data.
Seems this one would be provider generic, so no need to refer to PPC
specific concepts like HCALLs.
^ permalink raw reply
* Re: [PATCH] pci/hotplug/pnv-php: Remove probable double put
From: Oliver O'Halloran @ 2021-09-07 23:17 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: Linux Kernel Mailing List, Paul Mackerras, Xu Wang, linux-pci,
Bjorn Helgaas, linuxppc-dev
In-Reply-To: <0fa7ddfa-cd65-583e-a83f-4cbcd4e7337f@linux.ibm.com>
On Wed, Sep 8, 2021 at 8:02 AM Tyrel Datwyler <tyreld@linux.ibm.com> wrote:
>
> On 9/7/21 1:59 AM, Xu Wang wrote:
> > Device node iterators put the previous value of the index variable,
> > so an explicit put causes a double put.
> >
> > Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
> > ---
> > drivers/pci/hotplug/pnv_php.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
> > index 04565162a449..ed4d1a2c3f22 100644
> > --- a/drivers/pci/hotplug/pnv_php.c
> > +++ b/drivers/pci/hotplug/pnv_php.c
> > @@ -158,7 +158,6 @@ static void pnv_php_detach_device_nodes(struct device_node *parent)
> > for_each_child_of_node(parent, dn) {
> > pnv_php_detach_device_nodes(dn);
> >
> > - of_node_put(dn);
> > of_detach_node(dn);
>
> Are you sure this is a double put? This looks to me like its meant to drive tear
> down of the device by putting a long term reference and not the short term get
> that is part of the iterator.
Yeah, the put is there is to drop the initial ref so the node can be
released. It might be worth adding a comment.
^ permalink raw reply
* Re: [PATCH] pci/hotplug/pnv-php: Remove probable double put
From: Tyrel Datwyler @ 2021-09-07 22:01 UTC (permalink / raw)
To: Xu Wang, mpe, benh, paulus, bhelgaas
Cc: linux-pci, linuxppc-dev, linux-kernel
In-Reply-To: <20210907085946.21694-1-vulab@iscas.ac.cn>
On 9/7/21 1:59 AM, Xu Wang wrote:
> Device node iterators put the previous value of the index variable,
> so an explicit put causes a double put.
>
> Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
> ---
> drivers/pci/hotplug/pnv_php.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
> index 04565162a449..ed4d1a2c3f22 100644
> --- a/drivers/pci/hotplug/pnv_php.c
> +++ b/drivers/pci/hotplug/pnv_php.c
> @@ -158,7 +158,6 @@ static void pnv_php_detach_device_nodes(struct device_node *parent)
> for_each_child_of_node(parent, dn) {
> pnv_php_detach_device_nodes(dn);
>
> - of_node_put(dn);
> of_detach_node(dn);
Are you sure this is a double put? This looks to me like its meant to drive tear
down of the device by putting a long term reference and not the short term get
that is part of the iterator.
-Tyrel
> }
> }
>
^ permalink raw reply
* Re: [RESEND PATCH v4 1/4] drivers/nvdimm: Add nvdimm pmu structure
From: Dan Williams @ 2021-09-07 21:59 UTC (permalink / raw)
To: Kajol Jain
Cc: Linux NVDIMM, Santosh Sivaraj, maddy, Weiny, Ira, rnsastry,
Peter Zijlstra, Linux Kernel Mailing List, atrajeev,
Aneesh Kumar K.V, Vishal L Verma, Vaibhav Jain, Thomas Gleixner,
linuxppc-dev
In-Reply-To: <20210903050914.273525-2-kjain@linux.ibm.com>
Hi Kajol,
Apologies for the delay in responding to this series, some comments below:
On Thu, Sep 2, 2021 at 10:10 PM Kajol Jain <kjain@linux.ibm.com> wrote:
>
> A structure is added, called nvdimm_pmu, for performance
> stats reporting support of nvdimm devices. It can be used to add
> nvdimm pmu data such as supported events and pmu event functions
> like event_init/add/read/del with cpu hotplug support.
>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
> include/linux/nd.h | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/include/linux/nd.h b/include/linux/nd.h
> index ee9ad76afbba..712499cf7335 100644
> --- a/include/linux/nd.h
> +++ b/include/linux/nd.h
> @@ -8,6 +8,8 @@
> #include <linux/ndctl.h>
> #include <linux/device.h>
> #include <linux/badblocks.h>
> +#include <linux/platform_device.h>
> +#include <linux/perf_event.h>
>
> enum nvdimm_event {
> NVDIMM_REVALIDATE_POISON,
> @@ -23,6 +25,47 @@ enum nvdimm_claim_class {
> NVDIMM_CCLASS_UNKNOWN,
> };
>
> +/* Event attribute array index */
> +#define NVDIMM_PMU_FORMAT_ATTR 0
> +#define NVDIMM_PMU_EVENT_ATTR 1
> +#define NVDIMM_PMU_CPUMASK_ATTR 2
> +#define NVDIMM_PMU_NULL_ATTR 3
> +
> +/**
> + * struct nvdimm_pmu - data structure for nvdimm perf driver
> + *
> + * @name: name of the nvdimm pmu device.
> + * @pmu: pmu data structure for nvdimm performance stats.
> + * @dev: nvdimm device pointer.
> + * @functions(event_init/add/del/read): platform specific pmu functions.
This is not valid kernel-doc:
include/linux/nd.h:67: warning: Function parameter or member
'event_init' not described in 'nvdimm_pmu'
include/linux/nd.h:67: warning: Function parameter or member 'add' not
described in 'nvdimm_pmu'
include/linux/nd.h:67: warning: Function parameter or member 'del' not
described in 'nvdimm_pmu'
include/linux/nd.h:67: warning: Function parameter or member 'read'
not described in 'nvdimm_pmu'
...but I think rather than fixing those up 'struct nvdimm_pmu' should be pruned.
It's not clear to me that it is worth the effort to describe these
details to the nvdimm core which is just going to turn around and call
the pmu core. I'd just as soon have the driver call the pmu core
directly, optionally passing in attributes and callbacks that come
from the nvdimm core and/or the nvdimm provider.
Otherwise it's also not clear which of these structure members are
used at runtime vs purely used as temporary storage to pass parameters
to the pmu core.
> + * @attr_groups: data structure for events, formats and cpumask
> + * @cpu: designated cpu for counter access.
> + * @node: node for cpu hotplug notifier link.
> + * @cpuhp_state: state for cpu hotplug notification.
> + * @arch_cpumask: cpumask to get designated cpu for counter access.
> + */
> +struct nvdimm_pmu {
> + const char *name;
> + struct pmu pmu;
> + struct device *dev;
> + int (*event_init)(struct perf_event *event);
> + int (*add)(struct perf_event *event, int flags);
> + void (*del)(struct perf_event *event, int flags);
> + void (*read)(struct perf_event *event);
> + /*
> + * Attribute groups for the nvdimm pmu. Index 0 used for
> + * format attribute, index 1 used for event attribute,
> + * index 2 used for cpusmask attribute and index 3 kept as NULL.
> + */
> + const struct attribute_group *attr_groups[4];
Following from above, I'd rather this was organized as static
attributes with an is_visible() helper for the groups for any dynamic
aspects. That mirrors the behavior of nvdimm_create() and allows for
device drivers to compose the attribute groups from a core set and /
or a provider specific set.
> + int cpu;
> + struct hlist_node node;
> + enum cpuhp_state cpuhp_state;
> +
> + /* cpumask provided by arch/platform specific code */
> + struct cpumask arch_cpumask;
> +};
> +
> struct nd_device_driver {
> struct device_driver drv;
> unsigned long type;
> --
> 2.26.2
>
^ permalink raw reply
* RE: [PATCH v3] ftrace: Cleanup ftrace_dyn_arch_init()
From: LEROY Christophe @ 2021-09-07 15:55 UTC (permalink / raw)
To: Weizhao Ouyang, Steven Rostedt, Ingo Molnar
Cc: Rich Felker, linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Catalin Marinas, linux-kernel@vger.kernel.org,
James E.J. Bottomley, Guo Ren, H. Peter Anvin,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
Vincent Chen, Will Deacon, linux-s390@vger.kernel.org,
Yoshinori Sato, Helge Deller, x86@kernel.org, Russell King,
linux-csky@vger.kernel.org, Christian Borntraeger, Albert Ou,
Vasily Gorbik, Heiko Carstens, Borislav Petkov, Greentime Hu,
Paul Walmsley, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Michal Simek,
Thomas Bogendoerfer, Nick Hu, linux-parisc@vger.kernel.org,
linux-mips@vger.kernel.org, Palmer Dabbelt, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <20210907100524.1454928-1-o451686892@gmail.com>
> -----Message d'origine-----
> De : Linuxppc-dev <linuxppc-dev-
> bounces+christophe.leroy=csgroup.eu@lists.ozlabs.org> De la part de Weizhao
> Ouyang
>
> Most of ARCHs use empty ftrace_dyn_arch_init(), introduce a weak common
> ftrace_dyn_arch_init() to cleanup them.
>
> Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
> Acked-by: Heiko Carstens <hca@linux.ibm.com> (s390)
> Acked-by: Helge Deller <deller@gmx.de> (parisc)
>
> ---
> Changes in v3:
> -- fix unrecognized opcode on PowerPC
>
> Changes in v2:
> -- correct CONFIG_DYNAMIC_FTRACE on PowerPC
> -- add Acked-by tag
>
> ---
> arch/arm/kernel/ftrace.c | 5 -----
> arch/arm64/kernel/ftrace.c | 5 -----
> arch/csky/kernel/ftrace.c | 5 -----
> arch/ia64/kernel/ftrace.c | 6 ------
> arch/microblaze/kernel/ftrace.c | 5 -----
> arch/mips/include/asm/ftrace.h | 2 ++
> arch/nds32/kernel/ftrace.c | 5 -----
> arch/parisc/kernel/ftrace.c | 5 -----
> arch/powerpc/include/asm/ftrace.h | 4 ++++
> arch/riscv/kernel/ftrace.c | 5 -----
> arch/s390/kernel/ftrace.c | 5 -----
> arch/sh/kernel/ftrace.c | 5 -----
> arch/sparc/kernel/ftrace.c | 5 -----
> arch/x86/kernel/ftrace.c | 5 -----
> include/linux/ftrace.h | 1 -
> kernel/trace/ftrace.c | 5 +++++
> 16 files changed, 11 insertions(+), 62 deletions(-)
>
> diff --git a/arch/mips/include/asm/ftrace.h b/arch/mips/include/asm/ftrace.h
> index b463f2aa5a61..ed013e767390 100644
> --- a/arch/mips/include/asm/ftrace.h
> +++ b/arch/mips/include/asm/ftrace.h
> @@ -76,6 +76,8 @@ do { \
>
>
> #ifdef CONFIG_DYNAMIC_FTRACE
> +int __init ftrace_dyn_arch_init(void);
> +
Why ?
> static inline unsigned long ftrace_call_adjust(unsigned long addr)
> {
> return addr;
> diff --git a/arch/powerpc/include/asm/ftrace.h
> b/arch/powerpc/include/asm/ftrace.h
> index debe8c4f7062..b05c43f13a4d 100644
> --- a/arch/powerpc/include/asm/ftrace.h
> +++ b/arch/powerpc/include/asm/ftrace.h
> @@ -126,6 +126,10 @@ static inline void this_cpu_enable_ftrace(void) { }
> static inline void this_cpu_set_ftrace_enabled(u8 ftrace_enabled) { }
> static inline u8 this_cpu_get_ftrace_enabled(void) { return 1; }
> #endif /* CONFIG_PPC64 */
> +
> +#ifdef CONFIG_DYNAMIC_FTRACE
> +int __init ftrace_dyn_arch_init(void);
> +#endif /* CONFIG_DYNAMIC_FTRACE */
Why ?
> #endif /* !__ASSEMBLY__ */
>
> #endif /* _ASM_POWERPC_FTRACE */
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 832e65f06754..f1eca123d89d 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -573,7 +573,6 @@ ftrace_set_early_filter(struct ftrace_ops *ops, char
> *buf, int enable);
>
> /* defined in arch */
> extern int ftrace_ip_converted(unsigned long ip);
> -extern int ftrace_dyn_arch_init(void);
Why removing that ?
Have you tried to build kernel/trace/ftrace.o with C=2 ? It will likely tell you that the function is not declared and that it should be static
We could eventually consider that in the past, this generic declaration was unrelevant because the definitions where in the arch specific sections.
Now that you are implementing a generic weak version of this function, it would make sense to have a generic declaration as well.
I really don't see the point in duplicating the declaration of the function in the arch specific headers.
> extern void ftrace_replace_code(int enable);
> extern int ftrace_update_ftrace_func(ftrace_func_t func);
> extern void ftrace_caller(void);
Christophe
CS Group - Document Interne
^ permalink raw reply
* Re: [PATCH 1/5] KVM: rseq: Update rseq when processing NOTIFY_RESUME on xfer to KVM guest
From: Sean Christopherson @ 2021-09-07 14:38 UTC (permalink / raw)
To: Paolo Bonzini
Cc: KVM list, Peter Zijlstra, linux-kernel, Will Deacon, Guo Ren,
linux-kselftest, Ben Gardon, shuah, linux-s390, Shakeel Butt, gor,
Russell King, ARM Linux, linux-csky, Christian Borntraeger,
Ingo Molnar, Catalin Marinas, linux-mips, Boqun Feng, paulmck,
Heiko Carstens, rostedt, Mathieu Desnoyers, Andy Lutomirski,
Thomas Gleixner, Peter Foley, linux-arm-kernel,
Thomas Bogendoerfer, Oleg Nesterov, Paul Mackerras, linuxppc-dev
In-Reply-To: <425456d3-4772-2a1b-9cf3-a5b750b95c2e@redhat.com>
On Mon, Sep 06, 2021, Paolo Bonzini wrote:
> On 20/08/21 20:51, Mathieu Desnoyers wrote:
> > > Ah, or is it the case that rseq_cs is non-NULL if and only if userspace is in an
> > > rseq critical section, and because syscalls in critical sections are illegal, by
> > > definition clearing rseq_cs is a nop unless userspace is misbehaving.
> > Not quite, as I described above. But we want it to stay set so the CONFIG_DEBUG_RSEQ
> > code executed when returning from ioctl to userspace will be able to validate that
> > it is not nested within a rseq critical section.
> >
> > > If that's true, what about explicitly checking that at NOTIFY_RESUME? Or is it
> > > not worth the extra code to detect an error that will likely be caught anyways?
> > The error will indeed already be caught on return from ioctl to userspace, so I
> > don't see any added value in duplicating this check.
>
> Sean, can you send a v2 (even for this patch only would be okay)?
Made it all the way to v3 while you were out :-)
https://lkml.kernel.org/r/20210901203030.1292304-1-seanjc@google.com
^ permalink raw reply
* Re: [PATCH] powerpc/mce: Fix access error in mce handler
From: Ganesh @ 2021-09-07 8:11 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: mahesh, npiggin
In-Reply-To: <87y289natb.fsf@mpe.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 4846 bytes --]
On 9/6/21 6:03 PM, Michael Ellerman wrote:
> Ganesh Goudar <ganeshgr@linux.ibm.com> writes:
>> We queue an irq work for deferred processing of mce event
>> in realmode mce handler, where translation is disabled.
>> Queuing of the work may result in accessing memory outside
>> RMO region, such access needs the translation to be enabled
>> for an LPAR running with hash mmu else the kernel crashes.
>>
>> So enable the translation before queuing the work.
>>
>> Without this change following trace is seen on injecting machine
>> check error in an LPAR running with hash mmu.
> What type of error are you injecting?
SLB multihit in kernel mode.
>
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
>> CPU: 5 PID: 1883 Comm: insmod Tainted: G OE 5.14.0-mce+ #137
>> NIP: c000000000735d60 LR: c000000000318640 CTR: 0000000000000000
>> REGS: c00000001ebff9a0 TRAP: 0300 Tainted: G OE (5.14.0-mce+)
>> MSR: 8000000000001003 <SF,ME,RI,LE> CR: 28008228 XER: 00000001
>> CFAR: c00000000031863c DAR: c00000027fa8fe08 DSISR: 40000000 IRQMASK: 0
>> GPR00: c0000000003186d0 c00000001ebffc40 c000000001b0df00 c0000000016337e8
>> GPR04: c0000000016337e8 c00000027fa8fe08 0000000000000023 c0000000016337f0
>> GPR08: 0000000000000023 c0000000012ffe08 0000000000000000 c008000001460240
>> GPR12: 0000000000000000 c00000001ec9a900 c00000002ac4bd00 0000000000000000
>> GPR16: 00000000000005a0 c0080000006b0000 c0080000006b05a0 c000000000ff3068
>> GPR20: c00000002ac4bbc0 0000000000000001 c00000002ac4bbc0 c008000001490298
>> GPR24: c008000001490108 c000000001636198 c008000001470090 c008000001470058
>> GPR28: 0000000000000510 c008000001000000 c008000008000019 0000000000000019
>> NIP [c000000000735d60] llist_add_batch+0x0/0x40
>> LR [c000000000318640] __irq_work_queue_local+0x70/0xc0
>> Call Trace:
>> [c00000001ebffc40] [c00000001ebffc0c] 0xc00000001ebffc0c (unreliable)
>> [c00000001ebffc60] [c0000000003186d0] irq_work_queue+0x40/0x70
>> [c00000001ebffc80] [c00000000004425c] machine_check_queue_event+0xbc/0xd0
>> [c00000001ebffcf0] [c00000000000838c] machine_check_early_common+0x16c/0x1f4
>>
>> Fixes: 74c3354bc1d89 ("powerpc/pseries/mce: restore msr before returning from handler")
> Please explain in more detail why that commit caused this breakage.
After enabling translation in mce_handle_error() we used to leave it enabled to avoid
crashing here, but now with this commit we are restoring the MSR to disable translation.
Missed to mention it in commit log, I will add it.
>
>> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
>> index 47a683cd00d2..9d1e39d42e3e 100644
>> --- a/arch/powerpc/kernel/mce.c
>> +++ b/arch/powerpc/kernel/mce.c
>> @@ -249,6 +249,7 @@ void machine_check_queue_event(void)
>> {
>> int index;
>> struct machine_check_event evt;
>> + unsigned long msr;
>>
>> if (!get_mce_event(&evt, MCE_EVENT_RELEASE))
>> return;
>> @@ -262,8 +263,19 @@ void machine_check_queue_event(void)
>> memcpy(&local_paca->mce_info->mce_event_queue[index],
>> &evt, sizeof(evt));
>>
>> - /* Queue irq work to process this event later. */
>> - irq_work_queue(&mce_event_process_work);
>> + /* Queue irq work to process this event later. Before
>> + * queuing the work enable translation for non radix LPAR,
>> + * as irq_work_queue may try to access memory outside RMO
>> + * region.
>> + */
>> + if (!radix_enabled() && firmware_has_feature(FW_FEATURE_LPAR)) {
>> + msr = mfmsr();
>> + mtmsr(msr | MSR_IR | MSR_DR);
>> + irq_work_queue(&mce_event_process_work);
>> + mtmsr(msr);
>> + } else {
>> + irq_work_queue(&mce_event_process_work);
>> + }
>> }
> We already went to virtual mode and queued (different) irq work in
> arch/powerpc/platforms/pseries/ras.c:mce_handle_error()
>
> We also called save_mce_event() which also might have queued irq work,
> via machine_check_ue_event().
>
> So it really feels like something about the design is wrong if we have
> to go to virtual mode again and queue more irq work here.
>
> I guess we can probably merge this as a backportable fix, doing anything
> else would be a bigger change.
I agree.
>
> Looking at ras.c there's the comment:
>
> * Enable translation as we will be accessing per-cpu variables
> * in save_mce_event() which may fall outside RMO region, also
>
> But AFAICS it's only irq_work_queue() that touches anything percpu?
Yeah, we left the comment unchanged after doing some modifications around it,
It needs to be updated, ill send a separate patch for it.
>
> So maybe we should just not be using irq_work_queue(). It's a pretty
> thin wrapper around set_dec(1), perhaps we just need to hand-roll some
> real-mode friendly way of doing that.
You mean, have separate queue and run the work from timer handler?
>
> cheers
[-- Attachment #2: Type: text/html, Size: 6284 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] s390/pci: automatic error recovery
From: Niklas Schnelle @ 2021-09-07 12:21 UTC (permalink / raw)
To: Oliver O'Halloran
Cc: linux-s390, Pierre Morel, Matthew Rosato,
Linux Kernel Mailing List, Bjorn Helgaas, Linas Vepstas,
linuxppc-dev
In-Reply-To: <e739c2919f97e277849a1bc1324a20df6a7d59eb.camel@linux.ibm.com>
On Tue, 2021-09-07 at 10:45 +0200, Niklas Schnelle wrote:
> On Tue, 2021-09-07 at 12:04 +1000, Oliver O'Halloran wrote:
> > On Mon, Sep 6, 2021 at 7:49 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > > Patch 3 I already sent separately resulting in the discussion below but without
> > > a final conclusion.
> > >
> > > https://lore.kernel.org/lkml/20210720150145.640727-1-schnelle@linux.ibm.com/
> > >
> > > I believe even though there were some doubts about the use of
> > > pci_dev_is_added() by arch code the existing uses as well as the use in the
> > > final patch of this series warrant this export.
> >
> > The use of pci_dev_is_added() in arch/powerpc was because in the past
> > pci_bus_add_device() could be called before pci_device_add(). That was
> > fixed a while ago so It should be safe to remove those calls now.
>
> Hmm, ok that confirms Bjorns suspicion and explains how it came to be.
> I can certainly sent a patch for that. This would then leave only the
> existing use in s390 which I added because of a dead lock prevention
> and explained here:
> https://lore.kernel.org/lkml/87d15d5eead35c9eaa667958d057cf4a81a8bf13.camel@linux.ibm.com/
>
> Plus the need to use it in the recovery code of this series. I think in
> the EEH code the need for a similar check is alleviated by the checks
> in the beginning of
> arch/powerpc/kernel/eeh_driver.c:eeh_handle_normal_event() especially
> eeh_slot_presence_check() which checks presence via the hotplug slot.
> I guess we could use our own state tracking in a similar way but felt
> like pci_dev_is_added() is the more logical choice.
Looking into this again, I think we actually can't easily track this
state ourselves outside struct pci_dev. The reason for this is that
when e.g. arch/s390/pci/pci_sysfs.c:recover_store() removes the struct
pci_dev and scans it again the new struct pci_dev re-uses the same
struct zpci_dev because from a platform point of view the PCI device
was never removed but only disabled and re-enabled. Thus we can only
distinguish the stale struct pci_dev by looking at things stored in
struct pci_dev itself.
That said, I think for the recovery case we might be able to drop the
pci_dev_is_added() and rely on pdev->driver != NULL which we check
anyway and that should catch any PCI device that was already removed.
^ permalink raw reply
* Re: [PATCH] pci/hotplug/pnv-php: Remove probable double put
From: Bjorn Helgaas @ 2021-09-07 11:24 UTC (permalink / raw)
To: Xu Wang; +Cc: linux-kernel, paulus, linux-pci, bhelgaas, linuxppc-dev
In-Reply-To: <20210907085946.21694-1-vulab@iscas.ac.cn>
Make your subject line follow the previous convention.
Figure out if this is a "probable" or a real double put. If it's a
real double put, we should fix it. If it's only "probable," that
means we don't understand the problem yet.
On Tue, Sep 07, 2021 at 08:59:46AM +0000, Xu Wang wrote:
> Device node iterators put the previous value of the index variable,
> so an explicit put causes a double put.
>
> Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
> ---
> drivers/pci/hotplug/pnv_php.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
> index 04565162a449..ed4d1a2c3f22 100644
> --- a/drivers/pci/hotplug/pnv_php.c
> +++ b/drivers/pci/hotplug/pnv_php.c
> @@ -158,7 +158,6 @@ static void pnv_php_detach_device_nodes(struct device_node *parent)
> for_each_child_of_node(parent, dn) {
> pnv_php_detach_device_nodes(dn);
>
> - of_node_put(dn);
> of_detach_node(dn);
> }
> }
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH 3/9] xen/x86: make "earlyprintk=xen" work better for PVH Dom0
From: Jan Beulich @ 2021-09-07 10:09 UTC (permalink / raw)
To: Juergen Gross, Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org, Stefano Stabellini,
linuxppc-dev@lists.ozlabs.org, lkml
In-Reply-To: <4efa804e-3250-227f-00c7-347581366cd4@suse.com>
The xen_hvm_early_write() path better wouldn't be taken in this case;
while port 0xE9 can be used, the hypercall path is quite a bit more
efficient. Put that first, as it may also work for DomU-s (see also
xen_raw_console_write()).
While there also bail from the function when the first
domU_write_console() failed - later ones aren't going to succeed.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -632,17 +632,16 @@ static void xenboot_write_console(struct
unsigned int linelen, off = 0;
const char *pos;
+ if (dom0_write_console(0, string, len) >= 0)
+ return;
+
if (!xen_pv_domain()) {
xen_hvm_early_write(0, string, len);
return;
}
- dom0_write_console(0, string, len);
-
- if (xen_initial_domain())
+ if (domU_write_console(0, "(early) ", 8) < 0)
return;
-
- domU_write_console(0, "(early) ", 8);
while (off < len && NULL != (pos = strchr(string+off, '\n'))) {
linelen = pos-string+off;
if (off + linelen > len)
^ permalink raw reply
* [PATCH 5/9] xen/x86: make "earlyprintk=xen" work for HVM/PVH DomU
From: Jan Beulich @ 2021-09-07 10:10 UTC (permalink / raw)
To: Juergen Gross, Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org, Stefano Stabellini,
linuxppc-dev@lists.ozlabs.org, lkml
In-Reply-To: <4efa804e-3250-227f-00c7-347581366cd4@suse.com>
xenboot_write_console() is dealing with these quite fine so I don't see
why xenboot_console_setup() would return -ENOENT in this case.
Adjust documentation accordingly.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1266,7 +1266,7 @@
The VGA and EFI output is eventually overwritten by
the real console.
- The xen output can only be used by Xen PV guests.
+ The xen option can only be used in Xen domains.
The sclp output can only be used on s390.
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -618,10 +618,8 @@ static int __init xenboot_console_setup(
{
static struct xencons_info xenboot;
- if (xen_initial_domain())
+ if (xen_initial_domain() || !xen_pv_domain())
return 0;
- if (!xen_pv_domain())
- return -ENODEV;
return xencons_info_pv_init(&xenboot, 0);
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox