* [PATCH v2 2/7] KVM: PPC: Fix vmx/vsx mixup in mmio emulation
From: Fabiano Rosas @ 2022-01-06 20:02 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220106200304.4070825-1-farosas@linux.ibm.com>
The MMIO emulation code for vector instructions is duplicated between
VSX and VMX. When emulating VMX we should check the VMX copy size
instead of the VSX one.
Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction ...")
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kvm/powerpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 1e130bb087c4..92e552ab5a77 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1507,7 +1507,7 @@ int kvmppc_handle_vmx_load(struct kvm_vcpu *vcpu,
{
enum emulation_result emulated = EMULATE_DONE;
- if (vcpu->arch.mmio_vsx_copy_nums > 2)
+ if (vcpu->arch.mmio_vmx_copy_nums > 2)
return EMULATE_FAIL;
while (vcpu->arch.mmio_vmx_copy_nums) {
@@ -1604,7 +1604,7 @@ int kvmppc_handle_vmx_store(struct kvm_vcpu *vcpu,
unsigned int index = rs & KVM_MMIO_REG_MASK;
enum emulation_result emulated = EMULATE_DONE;
- if (vcpu->arch.mmio_vsx_copy_nums > 2)
+ if (vcpu->arch.mmio_vmx_copy_nums > 2)
return EMULATE_FAIL;
vcpu->arch.io_gpr = rs;
--
2.33.1
^ permalink raw reply related
* [PATCH v2 3/7] KVM: PPC: Fix mmio length message
From: Fabiano Rosas @ 2022-01-06 20:03 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220106200304.4070825-1-farosas@linux.ibm.com>
We check against 'bytes' but print 'run->mmio.len' which at that point
has an old value.
e.g. 16-byte load:
before:
__kvmppc_handle_load: bad MMIO length: 8
now:
__kvmppc_handle_load: bad MMIO length: 16
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/powerpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 92e552ab5a77..0b0818d032e1 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1246,7 +1246,7 @@ static int __kvmppc_handle_load(struct kvm_vcpu *vcpu,
if (bytes > sizeof(run->mmio.data)) {
printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
- run->mmio.len);
+ bytes);
}
run->mmio.phys_addr = vcpu->arch.paddr_accessed;
@@ -1335,7 +1335,7 @@ int kvmppc_handle_store(struct kvm_vcpu *vcpu,
if (bytes > sizeof(run->mmio.data)) {
printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
- run->mmio.len);
+ bytes);
}
run->mmio.phys_addr = vcpu->arch.paddr_accessed;
--
2.33.1
^ permalink raw reply related
* [PATCH v2 4/7] KVM: PPC: Don't use pr_emerg when mmio emulation fails
From: Fabiano Rosas @ 2022-01-06 20:03 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220106200304.4070825-1-farosas@linux.ibm.com>
If MMIO emulation fails we deliver a Program interrupt to the
guest. This is a normal event for the host, so use pr_info.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/powerpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 0b0818d032e1..3fc8057db4b4 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -308,7 +308,7 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
/* XXX Deliver Program interrupt to guest. */
- pr_emerg("%s: emulation failed (%08x)\n", __func__, last_inst);
+ pr_info("%s: emulation failed (%08x)\n", __func__, last_inst);
r = RESUME_HOST;
break;
}
--
2.33.1
^ permalink raw reply related
* [PATCH v2 5/7] KVM: PPC: mmio: Queue interrupt at kvmppc_emulate_mmio
From: Fabiano Rosas @ 2022-01-06 20:03 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220106200304.4070825-1-farosas@linux.ibm.com>
If MMIO emulation fails, we queue a Program interrupt to the
guest. Move that line up into kvmppc_emulate_mmio, which is where we
set RESUME_GUEST/HOST.
No functional change, just separation of responsibilities.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/emulate_loadstore.c | 4 +---
arch/powerpc/kvm/powerpc.c | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/emulate_loadstore.c b/arch/powerpc/kvm/emulate_loadstore.c
index 48272a9b9c30..ef50e8cfd988 100644
--- a/arch/powerpc/kvm/emulate_loadstore.c
+++ b/arch/powerpc/kvm/emulate_loadstore.c
@@ -355,10 +355,8 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
}
}
- if (emulated == EMULATE_FAIL) {
+ if (emulated == EMULATE_FAIL)
advance = 0;
- kvmppc_core_queue_program(vcpu, 0);
- }
trace_kvm_ppc_instr(inst, kvmppc_get_pc(vcpu), emulated);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 3fc8057db4b4..a2e78229d645 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -307,7 +307,7 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
u32 last_inst;
kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
- /* XXX Deliver Program interrupt to guest. */
+ kvmppc_core_queue_program(vcpu, 0);
pr_info("%s: emulation failed (%08x)\n", __func__, last_inst);
r = RESUME_HOST;
break;
--
2.33.1
^ permalink raw reply related
* [PATCH v2 6/7] KVM: PPC: mmio: Return to guest after emulation failure
From: Fabiano Rosas @ 2022-01-06 20:03 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220106200304.4070825-1-farosas@linux.ibm.com>
If MMIO emulation fails we don't want to crash the whole guest by
returning to userspace.
The original commit bbf45ba57eae ("KVM: ppc: PowerPC 440 KVM
implementation") added a todo:
/* XXX Deliver Program interrupt to guest. */
and later the commit d69614a295ae ("KVM: PPC: Separate loadstore
emulation from priv emulation") added the Program interrupt injection
but in another file, so I'm assuming it was missed that this block
needed to be altered.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/powerpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a2e78229d645..50e08635e18a 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -309,7 +309,7 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
kvmppc_core_queue_program(vcpu, 0);
pr_info("%s: emulation failed (%08x)\n", __func__, last_inst);
- r = RESUME_HOST;
+ r = RESUME_GUEST;
break;
}
default:
--
2.33.1
^ permalink raw reply related
* [PATCH v2 7/7] KVM: PPC: mmio: Reject instructions that access more than mmio.data size
From: Fabiano Rosas @ 2022-01-06 20:03 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin, aik
In-Reply-To: <20220106200304.4070825-1-farosas@linux.ibm.com>
The MMIO interface between the kernel and userspace uses a structure
that supports a maximum of 8-bytes of data. Instructions that access
more than that need to be emulated in parts.
We currently don't have generic support for splitting the emulation in
parts and each set of instructions needs to be explicitly included.
There's already an error message being printed when a load or store
exceeds the mmio.data buffer but we don't fail the emulation until
later at kvmppc_complete_mmio_load and even then we allow userspace to
make a partial copy of the data, which ends up overwriting some fields
of the mmio structure.
This patch makes the emulation fail earlier at kvmppc_handle_load|store,
which will send a Program interrupt to the guest. This is better than
allowing the guest to proceed with partial data.
Note that this was caught in a somewhat artificial scenario using
quadword instructions (lq/stq), there's no account of an actual guest
in the wild running instructions that are not properly emulated.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/powerpc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 50e08635e18a..a1643ca988e0 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -1247,6 +1247,7 @@ static int __kvmppc_handle_load(struct kvm_vcpu *vcpu,
if (bytes > sizeof(run->mmio.data)) {
printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
bytes);
+ return EMULATE_FAIL;
}
run->mmio.phys_addr = vcpu->arch.paddr_accessed;
@@ -1336,6 +1337,7 @@ int kvmppc_handle_store(struct kvm_vcpu *vcpu,
if (bytes > sizeof(run->mmio.data)) {
printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
bytes);
+ return EMULATE_FAIL;
}
run->mmio.phys_addr = vcpu->arch.paddr_accessed;
--
2.33.1
^ permalink raw reply related
* Re: [PATCH V2 1/2] tools/perf: Include global and local variants for p_stage_cyc sort key
From: Arnaldo Carvalho de Melo @ 2022-01-06 20:22 UTC (permalink / raw)
To: Athira Rajeev
Cc: maddy, Nageswara Sastry, linux-perf-users, Jiri Olsa, kajoljain,
Namhyung Kim, linuxppc-dev
In-Reply-To: <9FCC0543-29A8-455D-B2BC-299B332F45D2@linux.vnet.ibm.com>
Em Thu, Jan 06, 2022 at 04:21:05PM +0530, Athira Rajeev escreveu:
>
>
> > On 08-Dec-2021, at 9:21 AM, Nageswara Sastry <rnsastry@linux.ibm.com> wrote:
> >
> >
> >
> > On 07/12/21 8:22 pm, Arnaldo Carvalho de Melo wrote:
> >> Em Fri, Dec 03, 2021 at 07:50:37AM +0530, Athira Rajeev escreveu:
> >>> Sort key p_stage_cyc is used to present the latency
> >>> cycles spend in pipeline stages. perf tool has local
> >>> p_stage_cyc sort key to display this info. There is no
> >>> global variant available for this sort key. local variant
> >>> shows latency in a sinlge sample, whereas, global value
> >>> will be useful to present the total latency (sum of
> >>> latencies) in the hist entry. It represents latency
> >>> number multiplied by the number of samples.
> >>>
> >>> Add global (p_stage_cyc) and local variant
> >>> (local_p_stage_cyc) for this sort key. Use the
> >>> local_p_stage_cyc as default option for "mem" sort mode.
> >>> Also add this to list of dynamic sort keys and made the
> >>> "dynamic_headers" and "arch_specific_sort_keys" as static.
> >>>
> >>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> >>> Reported-by: Namhyung Kim <namhyung@kernel.org>
> >> I got this for v1, does it stand for v2?
> >> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
> >
> >
> > Tested with v2 also.
>
> Hi Arnaldo,
>
> If this patchset looks fine to you, can you please consider pulling it.
Thanks, applied to perf/core, for 5.17.
- Arnaldo
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_asrc: refine the check of available clock divider
From: Mark Brown @ 2022-01-06 20:28 UTC (permalink / raw)
To: perex, tiwai, Shengjiu Wang, Xiubo.Lee, alsa-devel, festevam,
nicoleotsuka, timur, lgirdwood
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1641380883-20709-1-git-send-email-shengjiu.wang@nxp.com>
On Wed, 5 Jan 2022 19:08:03 +0800, Shengjiu Wang wrote:
> According to RM, the clock divider range is from 1 to 8, clock
> prescaling ratio may be any power of 2 from 1 to 128.
> So the supported divider is not all the value between
> 1 and 1024, just limited value in that range.
>
> Create table for the supported divder and add function to
> check the clock divider is available by comparing with
> the table.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_asrc: refine the check of available clock divider
commit: 320386343451ab6a3577e0ee200dac56a6182944
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
^ permalink raw reply
* Re: [PATCH 0/3] ASoC: imx-card: several improvement and fixes
From: Mark Brown @ 2022-01-06 20:28 UTC (permalink / raw)
To: perex, tiwai, Xiubo.Lee, alsa-devel, festevam, nicoleotsuka,
timur, Shengjiu Wang
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1641292835-19085-1-git-send-email-shengjiu.wang@nxp.com>
On Tue, 4 Jan 2022 18:40:32 +0800, Shengjiu Wang wrote:
> Several improvement and fixes for AK codecs supported on i.MX platfroms
>
> Shengjiu Wang (3):
> ASoC: imx-card: Need special setting for ak4497 on i.MX8MQ
> ASoC: imx-card: Fix mclk calculation issue for akcodec
> ASoC: imx-card: improve the sound quality for low rate
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/3] ASoC: imx-card: Need special setting for ak4497 on i.MX8MQ
commit: 3349b3d0c63b8b6fcca58156d72407f0b2e101ac
[2/3] ASoC: imx-card: Fix mclk calculation issue for akcodec
commit: f331ae5fa59fbfb748317b290648fc3f1a50d932
[3/3] ASoC: imx-card: improve the sound quality for low rate
commit: 3969341813eb56d2dfc39bb64229359a6ae3c195
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
^ permalink raw reply
* Re: [PATCH v5] powerpc/pseries: read the lpar name from the firmware
From: Nathan Lynch @ 2022-01-06 21:13 UTC (permalink / raw)
To: Laurent Dufour; +Cc: tyreld, linuxppc-dev, linux-kernel
In-Reply-To: <20220106161339.74656-1-ldufour@linux.ibm.com>
Laurent Dufour <ldufour@linux.ibm.com> writes:
> The LPAR name may be changed after the LPAR has been started in the HMC.
> In that case lparstat command is not reporting the updated value because it
> reads it from the device tree which is read at boot time.
>
> However this value could be read from RTAS.
>
> Adding this value in the /proc/powerpc/lparcfg output allows to read the
> updated value.
>
> However the hypervisor, like Qemu/KVM, may not support this RTAS
> parameter. In that case the value reported in lparcfg is read from the
> device tree and so is not updated accordingly.
>
> Cc: Nathan Lynch <nathanl@linux.ibm.com>
> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
> ---
> v5:
> fallback to the device tree value if RTAS is not providing the value.
> v4:
> address Nathan's new comments limiting size of the buffer.
> v3:
> address Michael's comments.
> v2:
> address Nathan's comments.
> change title to partition_name aligning with existing partition_id
Thanks Laurent.
Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH] fs: btrfs: Disable BTRFS on platforms having 256K pages
From: Neal Gompa @ 2022-01-06 16:31 UTC (permalink / raw)
To: Qu Wenruo
Cc: linux-hexagon, Hector Martin, Josef Bacik,
Linux Kernel Mailing List, Chris Mason, David Sterba,
linuxppc-dev, Btrfs BTRFS
In-Reply-To: <6c7a6762-6bec-842b-70b4-4a53297687d1@gmx.com>
On Wed, Jan 5, 2022 at 7:05 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
> Hi Christophe,
>
> I'm recently enhancing the subpage support for btrfs, and my current
> branch should solve the problem for btrfs to support larger page sizes.
>
> But unfortunately my current test environment can only provide page size
> with 64K or 4K, no 16K or 128K/256K support.
>
> Mind to test my new branch on 128K page size systems?
> (256K page size support is still lacking though, which will be addressed
> in the future)
>
> https://github.com/adam900710/linux/tree/metadata_subpage_switch
>
The Linux Asahi folks have a 16K page environment (M1 Macs)...
Hector, could you look at it too?
--
真実はいつも一つ！/ Always, there's only one truth!
^ permalink raw reply
* Re: [PATCH v5] powerpc/pseries: read the lpar name from the firmware
From: Tyrel Datwyler @ 2022-01-06 21:38 UTC (permalink / raw)
To: Laurent Dufour, linuxppc-dev, linux-kernel; +Cc: Nathan Lynch
In-Reply-To: <20220106161339.74656-1-ldufour@linux.ibm.com>
On 1/6/22 8:13 AM, Laurent Dufour wrote:
> The LPAR name may be changed after the LPAR has been started in the HMC.
> In that case lparstat command is not reporting the updated value because it
> reads it from the device tree which is read at boot time.
>
> However this value could be read from RTAS.
>
> Adding this value in the /proc/powerpc/lparcfg output allows to read the
> updated value.
>
> However the hypervisor, like Qemu/KVM, may not support this RTAS
> parameter. In that case the value reported in lparcfg is read from the
> device tree and so is not updated accordingly.
>
> Cc: Nathan Lynch <nathanl@linux.ibm.com>
> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
My only nit would be that in general for consistency with other function names
_RTAS_ and _DT_ should be lowercase. Seeing as they are statically scoped within
lparcfg.c maybe its ok. Otherwise,
Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
> ---
> v5:
> fallback to the device tree value if RTAS is not providing the value.
> v4:
> address Nathan's new comments limiting size of the buffer.
> v3:
> address Michael's comments.
> v2:
> address Nathan's comments.
> change title to partition_name aligning with existing partition_id
> ---
> arch/powerpc/platforms/pseries/lparcfg.c | 93 ++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
> index c7940fcfc911..8ca08fc306e7 100644
> --- a/arch/powerpc/platforms/pseries/lparcfg.c
> +++ b/arch/powerpc/platforms/pseries/lparcfg.c
> @@ -311,6 +311,98 @@ static void parse_mpp_x_data(struct seq_file *m)
> seq_printf(m, "coalesce_pool_spurr=%ld\n", mpp_x_data.pool_spurr_cycles);
> }
>
> +/*
> + * PAPR defines, in section "7.3.16 System Parameters Option", the token 55 to
> + * read the LPAR name, and the largest output data to 4000 + 2 bytes length.
> + */
> +#define SPLPAR_LPAR_NAME_TOKEN 55
> +#define GET_SYS_PARM_BUF_SIZE 4002
> +#if GET_SYS_PARM_BUF_SIZE > RTAS_DATA_BUF_SIZE
> +#error "GET_SYS_PARM_BUF_SIZE is larger than RTAS_DATA_BUF_SIZE"
> +#endif
> +
> +/**
> + * Read the lpar name using the RTAS ibm,get-system-parameter call.
> + *
> + * The name read through this call is updated if changes are made by the end
> + * user on the hypervisor side.
> + *
> + * Some hypervisor (like Qemu) may not provide this value. In that case, a non
> + * null value is returned.
> + */
> +static int read_RTAS_lpar_name(struct seq_file *m)
> +{
> + int rc, len, token;
> + union {
> + char raw_buffer[GET_SYS_PARM_BUF_SIZE];
> + struct {
> + __be16 len;
> + char name[GET_SYS_PARM_BUF_SIZE-2];
> + };
> + } *local_buffer;
> +
> + token = rtas_token("ibm,get-system-parameter");
> + if (token == RTAS_UNKNOWN_SERVICE)
> + return -EINVAL;
> +
> + local_buffer = kmalloc(sizeof(*local_buffer), GFP_KERNEL);
> + if (!local_buffer)
> + return -ENOMEM;
> +
> + do {
> + spin_lock(&rtas_data_buf_lock);
> + memset(rtas_data_buf, 0, sizeof(*local_buffer));
> + rc = rtas_call(token, 3, 1, NULL, SPLPAR_LPAR_NAME_TOKEN,
> + __pa(rtas_data_buf), sizeof(*local_buffer));
> + if (!rc)
> + memcpy(local_buffer->raw_buffer, rtas_data_buf,
> + sizeof(local_buffer->raw_buffer));
> + spin_unlock(&rtas_data_buf_lock);
> + } while (rtas_busy_delay(rc));
> +
> + if (!rc) {
> + /* Force end of string */
> + len = min((int) be16_to_cpu(local_buffer->len),
> + (int) sizeof(local_buffer->name)-1);
> + local_buffer->name[len] = '\0';
> +
> + seq_printf(m, "partition_name=%s\n", local_buffer->name);
> + } else
> + rc = -ENODATA;
> +
> + kfree(local_buffer);
> + return rc;
> +}
> +
> +/**
> + * Read the LPAR name from the Device Tree.
> + *
> + * The value read in the DT is not updated if the end-user is touching the LPAR
> + * name on the hypervisor side.
> + */
> +static int read_DT_lpar_name(struct seq_file *m)
> +{
> + struct device_node *rootdn;
> + const char *name;
> +
> + rootdn = of_find_node_by_path("/");
> + if (!rootdn)
> + return -ENOENT;
> +
> + name = of_get_property(rootdn, "ibm,partition-name", NULL);
> + if (!name)
> + return -ENOENT;
> +
> + seq_printf(m, "partition_name=%s\n", name);
> + return 0;
> +}
> +
> +static void read_lpar_name(struct seq_file *m)
> +{
> + if (read_RTAS_lpar_name(m) && read_DT_lpar_name(m))
> + pr_err_once("Error can't get the LPAR name");
> +}
> +
> #define SPLPAR_CHARACTERISTICS_TOKEN 20
> #define SPLPAR_MAXLENGTH 1026*(sizeof(char))
>
> @@ -496,6 +588,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
>
> if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
> /* this call handles the ibm,get-system-parameter contents */
> + read_lpar_name(m);
> parse_system_parameter_string(m);
> parse_ppp_data(m);
> parse_mpp_data(m);
>
^ permalink raw reply
* [PATCH 00/16] Remove usage of the deprecated "pci-dma-compat.h" API
From: Christophe JAILLET @ 2022-01-06 21:45 UTC (permalink / raw)
To: arnd, hch, akpm, rth, ink, mattst88, mpe, benh, paulus, davem,
airlied, vkoul, hao.wu, trix, mdf, yilun.xu, awalls, mchehab,
sathya.prakash, sreekanth.reddy, suganath-prabu.subramani,
mporter, alex.bou9, bhelgaas
Cc: kernel-janitors, linux-scsi, MPT-FusionLinux.pdl, linux-fpga,
linux-pci, linux-kernel, dmaengine, Christophe JAILLET,
linux-alpha, sparclinux, linuxppc-dev, linux-media
This serie axes all the remaining usages of the deprecated "pci-dma-compat.h"
API.
All these patches have already been posted.
They have been generated with a coccinelle script.
The tricky parts are patches that use dma_alloc_coherent() because the correct
GFP flag has to be used in place of the previous embedded GFP_ATOMIC.
Patches 1-3 are already Reviewed. References to the corresponding mail is
given below the ---
Patch 1-2,4-10 are just generated from the coccinelle script. Only too long
lines have been hand modified. dma_alloc_coherent() modification are NOT part
of these patches.
Patch 3 also includes some 'dma_set_mask_and_coherent()' instead of
'pci_set_dma_mask()/pci_set_consistent_dma_mask()'.
I've left this additional modification because it was reviewed with it.
Patch 10-15 are the tricky parts. Explanation of which GFP flag is the right one
is given in each patch. It has been divided in several patches to ease review.
Patch 15 is the only one I'm slighly unsure with. The old code was using a
GFP_USER flag in the function. I'm not familiar with it.
I *guess* that GFP_KERNEL is fine, but maybe it should also be GFP_USER or left
as GFP_ATOMIC so that nothing is changed.
Patch 16 is the last step that remove "pci-dma-compat.h" and its only usage.
All patches, exept 1-2,6 that are architecture specific, have been compile tested.
After all that, a few rst files, 1 or 2 strings in error messages and some
error branching labels should still need some attention.
This is some minor issues.
Only the cover letter is sent to every one. Each patch is sent to the
corresponding maintainer(s) + Andrew Morton, Christoph Hellwig and Arnd Bergmann.
Best regards.
Christophe JAILLET (16):
alpha: Remove usage of the deprecated "pci-dma-compat.h" API
floppy: Remove usage of the deprecated "pci-dma-compat.h" API
fpga: dfl: pci: Remove usage of the deprecated "pci-dma-compat.h" API
media: Remove usage of the deprecated "pci-dma-compat.h" API
agp/intel: Remove usage of the deprecated "pci-dma-compat.h" API
sparc: Remove usage of the deprecated "pci-dma-compat.h" API
dmaengine: pch_dma: Remove usage of the deprecated "pci-dma-compat.h"
API
rapidio/tsi721: Remove usage of the deprecated "pci-dma-compat.h" API
media: v4l2-pci-skeleton: Remove usage of the deprecated
"pci-dma-compat.h" API
scsi: message: fusion: Remove usage of the deprecated
"pci-dma-compat.h" API
scsi: mptbase: Use dma_alloc_coherent() in 'mpt_alloc_fw_memory()'
scsi: mptbase: Use dma_alloc_coherent()
scsi: mptsas: Use dma_alloc_coherent() in
mptsas_exp_repmanufacture_info()
scsi: mptsas: Use dma_alloc_coherent()
scsi: mptctl: Use dma_alloc_coherent()
PCI: Remove usage of the deprecated "pci-dma-compat.h" API
arch/alpha/include/asm/floppy.h | 7 +-
arch/alpha/kernel/pci_iommu.c | 12 +--
arch/powerpc/include/asm/floppy.h | 8 +-
arch/sparc/kernel/ioport.c | 2 +-
drivers/char/agp/intel-gtt.c | 26 ++---
drivers/dma/pch_dma.c | 2 +-
drivers/fpga/dfl-pci.c | 14 +--
drivers/media/pci/cx18/cx18-queue.h | 6 +-
drivers/media/pci/ivtv/ivtv-queue.h | 25 +++--
drivers/media/pci/ivtv/ivtv-udma.h | 8 +-
drivers/message/fusion/mptbase.c | 149 ++++++++++++++++------------
drivers/message/fusion/mptctl.c | 82 +++++++++------
drivers/message/fusion/mptlan.c | 90 +++++++++--------
drivers/message/fusion/mptsas.c | 94 +++++++++---------
drivers/rapidio/devices/tsi721.c | 8 +-
include/linux/pci-dma-compat.h | 129 ------------------------
include/linux/pci.h | 3 -
samples/v4l/v4l2-pci-skeleton.c | 2 +-
18 files changed, 289 insertions(+), 378 deletions(-)
delete mode 100644 include/linux/pci-dma-compat.h
--
2.32.0
^ permalink raw reply
* [PATCH 02/16] floppy: Remove usage of the deprecated "pci-dma-compat.h" API
From: Christophe JAILLET @ 2022-01-06 21:47 UTC (permalink / raw)
To: arnd, hch, akpm, mpe, benh, paulus
Cc: kernel-janitors, Christophe JAILLET, linuxppc-dev, linux-kernel,
Christoph Hellwig
In-Reply-To: <cover.1641500561.git.christophe.jaillet@wanadoo.fr>
In [1], Christoph Hellwig has proposed to remove the wrappers in
include/linux/pci-dma-compat.h.
Some reasons why this API should be removed have been given by Julia
Lawall in [2].
A coccinelle script has been used to perform the needed transformation.
It can be found in [3].
[1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/
[2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/
[3]: https://lore.kernel.org/kernel-janitors/20200716192821.321233-1-christophe.jaillet@wanadoo.fr/
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
Reviewed in: https://lore.kernel.org/kernel-janitors/YdLAqi+WQu4ZhAxE@infradead.org/
---
arch/powerpc/include/asm/floppy.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/floppy.h b/arch/powerpc/include/asm/floppy.h
index 7af9a68fd949..f8ce178b43b7 100644
--- a/arch/powerpc/include/asm/floppy.h
+++ b/arch/powerpc/include/asm/floppy.h
@@ -134,17 +134,19 @@ static int hard_dma_setup(char *addr, unsigned long size, int mode, int io)
int dir;
doing_vdma = 0;
- dir = (mode == DMA_MODE_READ) ? PCI_DMA_FROMDEVICE : PCI_DMA_TODEVICE;
+ dir = (mode == DMA_MODE_READ) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
if (bus_addr
&& (addr != prev_addr || size != prev_size || dir != prev_dir)) {
/* different from last time -- unmap prev */
- pci_unmap_single(isa_bridge_pcidev, bus_addr, prev_size, prev_dir);
+ dma_unmap_single(&isa_bridge_pcidev->dev, bus_addr, prev_size,
+ prev_dir);
bus_addr = 0;
}
if (!bus_addr) /* need to map it */
- bus_addr = pci_map_single(isa_bridge_pcidev, addr, size, dir);
+ bus_addr = dma_map_single(&isa_bridge_pcidev->dev, addr, size,
+ dir);
/* remember this one as prev */
prev_addr = addr;
--
2.32.0
^ permalink raw reply related
* Re: [PATCH 00/13] powerpc/bpf: Some fixes and updates
From: Daniel Borkmann @ 2022-01-06 21:46 UTC (permalink / raw)
To: Naveen N. Rao, Michael Ellerman, Alexei Starovoitov
Cc: ykaliuta, johan.almbladh, linuxppc-dev, song, bpf, Jiri Olsa,
Hari Bathini
In-Reply-To: <cover.1641468127.git.naveen.n.rao@linux.vnet.ibm.com>
Hi Naveen,
On 1/6/22 12:45 PM, Naveen N. Rao wrote:
> A set of fixes and updates to powerpc BPF JIT:
> - Patches 1-3 fix issues with the existing powerpc JIT and are tagged
> for -stable.
> - Patch 4 fixes a build issue with bpf selftests on powerpc.
> - Patches 5-9 handle some corner cases and make some small improvements.
> - Patches 10-13 optimize how function calls are handled in ppc64.
>
> Patches 7 and 8 were previously posted, and while patch 7 has no
> changes, patch 8 has been reworked to handle BPF_EXIT differently.
Is the plan to route these via ppc trees? Fwiw, patch 1 and 4 look generic
and in general good to me, we could also take these two via bpf-next tree
given outside of arch/powerpc/? Whichever works best.
Thanks,
Daniel
^ permalink raw reply
* Re: [5.16.0-rc5][ppc][net] kernel oops when hotplug remove of vNIC interface
From: Sukadev Bhattiprolu @ 2022-01-06 22:24 UTC (permalink / raw)
To: Michael Ellerman
Cc: dumazet, Dany Madden, netdev, linux-kernel, Abdul Haleem,
alexandr.lobakin, brian King, Jakub Kicinski, linuxppc-dev
In-Reply-To: <87lezt3398.fsf@mpe.ellerman.id.au>
Michael Ellerman [mpe@ellerman.id.au] wrote:
> Jakub Kicinski <kuba@kernel.org> writes:
> > On Wed, 5 Jan 2022 13:56:53 +0530 Abdul Haleem wrote:
> >> Greeting's
> >>
> >> Mainline kernel 5.16.0-rc5 panics when DLPAR ADD of vNIC device on my
> >> Powerpc LPAR
> >>
> >> Perform below dlpar commands in a loop from linux OS
> >>
> >> drmgr -r -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
> >> drmgr -a -c slot -s U9080.HEX.134C488-V1-C3 -w 5 -d 1
> >>
> >> after 7th iteration, the kernel panics with below messages
> >>
> >> console messages:
> >> [102056] ibmvnic 30000003 env3: Sending CRQ: 801e000864000000
> >> 0060000000000000
> >> <intr> ibmvnic 30000003 env3: Handling CRQ: 809e000800000000
> >> 0000000000000000
> >> [102056] ibmvnic 30000003 env3: Disabling tx_scrq[0] irq
> >> [102056] ibmvnic 30000003 env3: Disabling tx_scrq[1] irq
> >> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[0] irq
> >> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[1] irq
> >> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[2] irq
> >> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[3] irq
> >> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[4] irq
> >> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[5] irq
> >> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
> >> [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
> >> [102056] ibmvnic 30000003 env3: Replenished 8 pools
> >> Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
> >> BUG: Kernel NULL pointer dereference on read at 0x00000010
> >> Faulting instruction address: 0xc000000000a3c840
> >> Oops: Kernel access of bad area, sig: 11 [#1]
> >> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
> >> Modules linked in: bridge stp llc ib_core rpadlpar_io rpaphp nfnetlink
> >> tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag
> >> bonding rfkill ibmvnic sunrpc pseries_rng xts vmx_crypto gf128mul
> >> sch_fq_codel binfmt_misc ip_tables ext4 mbcache jbd2 dm_service_time
> >> sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth dm_multipath dm_mirror
> >> dm_region_hash dm_log dm_mod fuse
> >> CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted
> >> 5.16.0-rc5-autotest-g6441998e2e37 #1
> >> Workqueue: events_long __ibmvnic_reset [ibmvnic]
> >> NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
> >> REGS: c0000000548e37e0 TRAP: 0300 Not tainted
> >> (5.16.0-rc5-autotest-g6441998e2e37)
> >> MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004
> >> CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
> >> GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
> >> GPR04: c000000c7d1a7e00 fffffffffffffff6 0000000000000027 c000000c7d1a7e08
> >> GPR08: 0000000000000023 0000000000000000 0000000000000010 c0080000029bdd10
> >> GPR12: c000000000a3c820 c000000c7fca6680 0000000000000000 c000000133016bf8
> >> GPR16: 00000000000003fe 0000000000001000 0000000000000002 0000000000000008
> >> GPR20: c000000133016eb0 0000000000000000 0000000000000000 0000000000000003
> >> GPR24: c000000133016000 c000000133017168 0000000020000000 c000000133016a00
> >> GPR28: 0000000000000006 c000000133016a00 0000000000000001 c000000133016000
> >> NIP [c000000000a3c840] napi_enable+0x20/0xc0
> >> LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
> >> Call Trace:
> >> [c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
> >> [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
> >> [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
> >> [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
> >> [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
> >> [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
> >> [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
> >> Instruction dump:
> >> 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
> >> 38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020
> >> ---[ end trace 5f8033b08fd27706 ]---
> >> radix-mmu: Page sizes from device-tree:
> >>
> >> the fault instruction points to
> >>
> >> [root@ltcden11-lp1 boot]# gdb -batch
> >> vmlinuz-5.16.0-rc5-autotest-g6441998e2e37 -ex 'list *(0xc000000000a3c840)'
> >> 0xc000000000a3c840 is in napi_enable (net/core/dev.c:6966).
> >> 6961 void napi_enable(struct napi_struct *n)
> >> 6962 {
> >> 6963 unsigned long val, new;
> >> 6964
> >> 6965 do {
> >> 6966 val = READ_ONCE(n->state);
> >
> > If n is NULL here that's gotta be a driver problem.
>
> Definitely looks like it, the disassembly is:
>
> not r9,r9
> clrldi r3,r9,63
> blr # end of previous function
> nop
> addis r2,r12,491 # function entry
> addi r2,r2,14816
> stdu r1,-48(r1) # stack frame creation
> li r5,-10
> ld r9,4352(r13)
> std r9,40(r1)
> li r9,0
> ld r8,16(r3) # load from r3 (n) + 16
>
>
> The register dump shows that r3 is NULL, and it comes directly from the
> caller. So we've been called with n = NULL.
Yeah, Good catch Abdul.
I suspect its due to the release_resources() in __ibmvnic_open(). The
problem is hard to reproduce but we are testing following patch with
error injection. Will formally submit after testing/review.
---
From 8a78083e5ec6914be197352f391bfa17420a147c Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date: Wed, 5 Jan 2022 16:22:58 -0500
Subject: [PATCH 1/1] ibmvnic: don't release napi in __ibmvnic_open()
If __ibmvnic_open() encounters an error such as when setting link state,
it calls release_resources() which frees the napi structures needlessly.
Instead, have __ibmvnic_open() only clean up the work it did so far (i.e.
disable napi and irqs) and leave the rest to the callers.
If caller of __ibmvnic_open() is ibmvnic_open(), it should release the
resources immediately. If the caller is do_reset() or do_hard_reset(),
they will release the resources on the next reset.
Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 0bb3911dd014..34efba6c117b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -110,6 +110,7 @@ static void ibmvnic_tx_scrq_clean_buffer(struct ibmvnic_adapter *adapter,
struct ibmvnic_sub_crq_queue *tx_scrq);
static void free_long_term_buff(struct ibmvnic_adapter *adapter,
struct ibmvnic_long_term_buff *ltb);
+static void ibmvnic_disable_irqs(struct ibmvnic_adapter *adapter);
struct ibmvnic_stat {
char name[ETH_GSTRING_LEN];
@@ -1418,7 +1419,7 @@ static int __ibmvnic_open(struct net_device *netdev)
rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_UP);
if (rc) {
ibmvnic_napi_disable(adapter);
- release_resources(adapter);
+ ibmvnic_disable_irqs(adapter);
return rc;
}
@@ -1468,9 +1469,6 @@ static int ibmvnic_open(struct net_device *netdev)
rc = init_resources(adapter);
if (rc) {
netdev_err(netdev, "failed to initialize resources\n");
- release_resources(adapter);
- release_rx_pools(adapter);
- release_tx_pools(adapter);
goto out;
}
}
@@ -1487,6 +1485,12 @@ static int ibmvnic_open(struct net_device *netdev)
adapter->state = VNIC_OPEN;
rc = 0;
}
+ if (rc) {
+ release_resources(adapter);
+ release_rx_pools(adapter);
+ release_tx_pools(adapter);
+ }
+
return rc;
}
--
2.27.0
>
> cheers
^ permalink raw reply related
* Re: [PATCH v4] powerpc/pseries: read the lpar name from the firmware
From: Michael Ellerman @ 2022-01-06 23:09 UTC (permalink / raw)
To: Laurent Dufour; +Cc: Nathan Lynch, linuxppc-dev, linux-kernel
In-Reply-To: <25527544-b0ac-596c-3876-560493b99f6b@linux.ibm.com>
Laurent Dufour <ldufour@linux.ibm.com> writes:
> Happy New Year, Michael!
>
> Do you consider taking that patch soon?
I did but I was hoping you and Nathan could come to an agreement.
Looks like you did while I was sleeping, perfect :)
I'll pick up v5.
cheers
> On 07/12/2021, 18:11:09, Laurent Dufour wrote:
>> The LPAR name may be changed after the LPAR has been started in the HMC.
>> In that case lparstat command is not reporting the updated value because it
>> reads it from the device tree which is read at boot time.
>>
>> However this value could be read from RTAS.
>>
>> Adding this value in the /proc/powerpc/lparcfg output allows to read the
>> updated value.
>>
>> Cc: Nathan Lynch <nathanl@linux.ibm.com>
>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>> ---
>> v4:
>> address Nathan's new comments limiting size of the buffer.
>> v3:
>> address Michael's comments.
>> v2:
>> address Nathan's comments.
>> change title to partition_name aligning with existing partition_id
>> ---
>> arch/powerpc/platforms/pseries/lparcfg.c | 54 ++++++++++++++++++++++++
>> 1 file changed, 54 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
>> index f71eac74ea92..058d9a5fe545 100644
>> --- a/arch/powerpc/platforms/pseries/lparcfg.c
>> +++ b/arch/powerpc/platforms/pseries/lparcfg.c
>> @@ -311,6 +311,59 @@ static void parse_mpp_x_data(struct seq_file *m)
>> seq_printf(m, "coalesce_pool_spurr=%ld\n", mpp_x_data.pool_spurr_cycles);
>> }
>>
>> +/*
>> + * PAPR defines, in section "7.3.16 System Parameters Option", the token 55 to
>> + * read the LPAR name, and the largest output data to 4000 + 2 bytes length.
>> + */
>> +#define SPLPAR_LPAR_NAME_TOKEN 55
>> +#define GET_SYS_PARM_BUF_SIZE 4002
>> +#if GET_SYS_PARM_BUF_SIZE > RTAS_DATA_BUF_SIZE
>> +#error "GET_SYS_PARM_BUF_SIZE is larger than RTAS_DATA_BUF_SIZE"
>> +#endif
>> +static void read_lpar_name(struct seq_file *m)
>> +{
>> + int rc, len, token;
>> + union {
>> + char raw_buffer[GET_SYS_PARM_BUF_SIZE];
>> + struct {
>> + __be16 len;
>> + char name[GET_SYS_PARM_BUF_SIZE-2];
>> + };
>> + } *local_buffer;
>> +
>> + token = rtas_token("ibm,get-system-parameter");
>> + if (token == RTAS_UNKNOWN_SERVICE)
>> + return;
>> +
>> + local_buffer = kmalloc(sizeof(*local_buffer), GFP_KERNEL);
>> + if (!local_buffer)
>> + return;
>> +
>> + do {
>> + spin_lock(&rtas_data_buf_lock);
>> + memset(rtas_data_buf, 0, sizeof(*local_buffer));
>> + rc = rtas_call(token, 3, 1, NULL, SPLPAR_LPAR_NAME_TOKEN,
>> + __pa(rtas_data_buf), sizeof(*local_buffer));
>> + if (!rc)
>> + memcpy(local_buffer->raw_buffer, rtas_data_buf,
>> + sizeof(local_buffer->raw_buffer));
>> + spin_unlock(&rtas_data_buf_lock);
>> + } while (rtas_busy_delay(rc));
>> +
>> + if (!rc) {
>> + /* Force end of string */
>> + len = min((int) be16_to_cpu(local_buffer->len),
>> + (int) sizeof(local_buffer->name)-1);
>> + local_buffer->name[len] = '\0';
>> +
>> + seq_printf(m, "partition_name=%s\n", local_buffer->name);
>> + } else
>> + pr_err_once("Error calling get-system-parameter (0x%x)\n", rc);
>> +
>> + kfree(local_buffer);
>> +}
>> +
>> +
>> #define SPLPAR_CHARACTERISTICS_TOKEN 20
>> #define SPLPAR_MAXLENGTH 1026*(sizeof(char))
>>
>> @@ -496,6 +549,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
>>
>> if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
>> /* this call handles the ibm,get-system-parameter contents */
>> + read_lpar_name(m);
>> parse_system_parameter_string(m);
>> parse_ppp_data(m);
>> parse_mpp_data(m);
^ permalink raw reply
* Re: [PATCH] fs: btrfs: Disable BTRFS on platforms having 256K pages
From: Qu Wenruo @ 2022-01-07 0:13 UTC (permalink / raw)
To: Neal Gompa
Cc: linux-hexagon, Hector Martin, Josef Bacik,
Linux Kernel Mailing List, Chris Mason, David Sterba,
linuxppc-dev, Btrfs BTRFS
In-Reply-To: <CAEg-Je9UJDJ=hvLLqQDsHijWnxh1Z1CwaLKCFm+-bLTfCFingg@mail.gmail.com>
On 2022/1/7 00:31, Neal Gompa wrote:
> On Wed, Jan 5, 2022 at 7:05 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>> Hi Christophe,
>>
>> I'm recently enhancing the subpage support for btrfs, and my current
>> branch should solve the problem for btrfs to support larger page sizes.
>>
>> But unfortunately my current test environment can only provide page size
>> with 64K or 4K, no 16K or 128K/256K support.
>>
>> Mind to test my new branch on 128K page size systems?
>> (256K page size support is still lacking though, which will be addressed
>> in the future)
>>
>> https://github.com/adam900710/linux/tree/metadata_subpage_switch
>>
>
> The Linux Asahi folks have a 16K page environment (M1 Macs)...
Su Yue kindly helped me testing 16K page size, and it's pretty OK there.
So I'm not that concerned.
It's 128K page size that I'm a little concerned, and I have not machine
supporting that large page size to do the test.
Thanks,
Qu
>
> Hector, could you look at it too?
>
>
>
^ permalink raw reply
* Re: [PATCH v2 3/7] KVM: PPC: Fix mmio length message
From: Alexey Kardashevskiy @ 2022-01-07 0:19 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev, npiggin
In-Reply-To: <20220106200304.4070825-4-farosas@linux.ibm.com>
On 07/01/2022 07:03, Fabiano Rosas wrote:
> We check against 'bytes' but print 'run->mmio.len' which at that point
> has an old value.
>
> e.g. 16-byte load:
>
> before:
> __kvmppc_handle_load: bad MMIO length: 8
>
> now:
> __kvmppc_handle_load: bad MMIO length: 16
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> arch/powerpc/kvm/powerpc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 92e552ab5a77..0b0818d032e1 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -1246,7 +1246,7 @@ static int __kvmppc_handle_load(struct kvm_vcpu *vcpu,
>
> if (bytes > sizeof(run->mmio.data)) {
> printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
> - run->mmio.len);
> + bytes);
"return EMULATE_FAIL;" here and below as there is really no point in
trashing kvm_run::mmio (not much harm too but still) and this code does
not handle more than 8 bytes anyway.
> }
>
> run->mmio.phys_addr = vcpu->arch.paddr_accessed;
> @@ -1335,7 +1335,7 @@ int kvmppc_handle_store(struct kvm_vcpu *vcpu,
>
> if (bytes > sizeof(run->mmio.data)) {
> printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
> - run->mmio.len);
> + bytes);
> }
>
> run->mmio.phys_addr = vcpu->arch.paddr_accessed;
--
Alexey
^ permalink raw reply
* Re: [PATCH v2 5/7] KVM: PPC: mmio: Queue interrupt at kvmppc_emulate_mmio
From: Alexey Kardashevskiy @ 2022-01-07 0:24 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev, npiggin
In-Reply-To: <20220106200304.4070825-6-farosas@linux.ibm.com>
On 07/01/2022 07:03, Fabiano Rosas wrote:
> If MMIO emulation fails, we queue a Program interrupt to the
> guest. Move that line up into kvmppc_emulate_mmio, which is where we
> set RESUME_GUEST/HOST.
>
> No functional change, just separation of responsibilities.
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> arch/powerpc/kvm/emulate_loadstore.c | 4 +---
> arch/powerpc/kvm/powerpc.c | 2 +-
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kvm/emulate_loadstore.c b/arch/powerpc/kvm/emulate_loadstore.c
> index 48272a9b9c30..ef50e8cfd988 100644
> --- a/arch/powerpc/kvm/emulate_loadstore.c
> +++ b/arch/powerpc/kvm/emulate_loadstore.c
> @@ -355,10 +355,8 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
> }
> }
>
> - if (emulated == EMULATE_FAIL) {
> + if (emulated == EMULATE_FAIL)
> advance = 0;
You can now drop @advance by moving the "if" few lines down.
> - kvmppc_core_queue_program(vcpu, 0);
> - }
>
> trace_kvm_ppc_instr(inst, kvmppc_get_pc(vcpu), emulated);
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 3fc8057db4b4..a2e78229d645 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -307,7 +307,7 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
> u32 last_inst;
>
> kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
> - /* XXX Deliver Program interrupt to guest. */
> + kvmppc_core_queue_program(vcpu, 0);
> pr_info("%s: emulation failed (%08x)\n", __func__, last_inst);
> r = RESUME_HOST;
> break;
--
Alexey
^ permalink raw reply
* Re: [PATCH v2 7/7] KVM: PPC: mmio: Reject instructions that access more than mmio.data size
From: Alexey Kardashevskiy @ 2022-01-07 0:30 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev, npiggin
In-Reply-To: <20220106200304.4070825-8-farosas@linux.ibm.com>
On 07/01/2022 07:03, Fabiano Rosas wrote:
> The MMIO interface between the kernel and userspace uses a structure
> that supports a maximum of 8-bytes of data. Instructions that access
> more than that need to be emulated in parts.
>
> We currently don't have generic support for splitting the emulation in
> parts and each set of instructions needs to be explicitly included.
>
> There's already an error message being printed when a load or store
> exceeds the mmio.data buffer but we don't fail the emulation until
> later at kvmppc_complete_mmio_load and even then we allow userspace to
> make a partial copy of the data, which ends up overwriting some fields
> of the mmio structure.
>
> This patch makes the emulation fail earlier at kvmppc_handle_load|store,
> which will send a Program interrupt to the guest. This is better than
> allowing the guest to proceed with partial data.
>
> Note that this was caught in a somewhat artificial scenario using
> quadword instructions (lq/stq), there's no account of an actual guest
> in the wild running instructions that are not properly emulated.
Ah thereee it is :-)
I'd merge it into 3/7.
anyway,
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> arch/powerpc/kvm/powerpc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 50e08635e18a..a1643ca988e0 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -1247,6 +1247,7 @@ static int __kvmppc_handle_load(struct kvm_vcpu *vcpu,
> if (bytes > sizeof(run->mmio.data)) {
> printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
> bytes);
> + return EMULATE_FAIL;
> }
>
> run->mmio.phys_addr = vcpu->arch.paddr_accessed;
> @@ -1336,6 +1337,7 @@ int kvmppc_handle_store(struct kvm_vcpu *vcpu,
> if (bytes > sizeof(run->mmio.data)) {
> printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
> bytes);
> + return EMULATE_FAIL;
> }
>
> run->mmio.phys_addr = vcpu->arch.paddr_accessed;
--
Alexey
^ permalink raw reply
* Re: [PATCH v2 6/7] KVM: PPC: mmio: Return to guest after emulation failure
From: Alexey Kardashevskiy @ 2022-01-07 1:08 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev, npiggin
In-Reply-To: <20220106200304.4070825-7-farosas@linux.ibm.com>
On 07/01/2022 07:03, Fabiano Rosas wrote:
> If MMIO emulation fails we don't want to crash the whole guest by
> returning to userspace.
>
> The original commit bbf45ba57eae ("KVM: ppc: PowerPC 440 KVM
> implementation") added a todo:
>
> /* XXX Deliver Program interrupt to guest. */
>
> and later the commit d69614a295ae ("KVM: PPC: Separate loadstore
> emulation from priv emulation") added the Program interrupt injection
> but in another file, so I'm assuming it was missed that this block
> needed to be altered.
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Looks right.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
but this means if I want to keep debugging those kvm selftests in
comfort, I'll have to have some exception handlers in the vm as
otherwise the failing $pc is lost after this change :)
> ---
> arch/powerpc/kvm/powerpc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index a2e78229d645..50e08635e18a 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -309,7 +309,7 @@ int kvmppc_emulate_mmio(struct kvm_vcpu *vcpu)
> kvmppc_get_last_inst(vcpu, INST_GENERIC, &last_inst);
> kvmppc_core_queue_program(vcpu, 0);
> pr_info("%s: emulation failed (%08x)\n", __func__, last_inst);
> - r = RESUME_HOST;
> + r = RESUME_GUEST;
> break;
> }
> default:
--
Alexey
^ permalink raw reply
* Re: [PATCH] soc: fsl: qe: Check of ioremap return value
From: Li Yang @ 2022-01-07 2:22 UTC (permalink / raw)
To: Jiasheng Jiang
Cc: linuxppc-dev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Zhao Qiang
In-Reply-To: <20211230014543.1799867-1-jiasheng@iscas.ac.cn>
On Thu, Dec 30, 2021 at 9:47 AM Jiasheng Jiang <jiasheng@iscas.ac.cn> wrote:
>
> As the possible failure of the ioremap(), the par_io could be NULL.
> Therefore it should be better to check it and return error in order to
> guarantee the success of the initiation.
> But, I also notice that all the caller like mpc85xx_qe_par_io_init() in
> `arch/powerpc/platforms/85xx/common.c` don't check the return value of
> the par_io_init().
> Actually, par_io_init() needs to check to handle the potential error.
> I will submit another patch to fix that.
> Anyway, par_io_init() itsely should be fixed.
>
> Fixes: 7aa1aa6ecec2 ("QE: Move QE from arch/powerpc to drivers/soc")
> Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Applied for next. Thanks.
> ---
> drivers/soc/fsl/qe/qe_io.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/soc/fsl/qe/qe_io.c b/drivers/soc/fsl/qe/qe_io.c
> index e277c827bdf3..a5e2d0e5ab51 100644
> --- a/drivers/soc/fsl/qe/qe_io.c
> +++ b/drivers/soc/fsl/qe/qe_io.c
> @@ -35,6 +35,8 @@ int par_io_init(struct device_node *np)
> if (ret)
> return ret;
> par_io = ioremap(res.start, resource_size(&res));
> + if (!par_io)
> + return -ENOMEM;
>
> if (!of_property_read_u32(np, "num-ports", &num_ports))
> num_par_io_ports = num_ports;
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH] soc: fsl: qe: fix typo in a comment
From: Li Yang @ 2022-01-07 2:25 UTC (permalink / raw)
To: wangborong
Cc: linuxppc-dev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Zhao Qiang
In-Reply-To: <20211211090845.252700-1-wangborong@cdjrlc.com>
On Sat, Dec 11, 2021 at 5:12 PM Jason Wang <wangborong@cdjrlc.com> wrote:
>
> The double `is' in the comment in line 150 is repeated. Remove one
> of them from the comment.
Looks like you also removed a redundant tab in a new line. We
probably can squeeze this trivial cleanup in, but we need to mention
it.
>
> Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Applied for next with commit message updated.
> ---
> drivers/soc/fsl/qe/qe.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
> index 4d38c80f8be8..b3c226eb5292 100644
> --- a/drivers/soc/fsl/qe/qe.c
> +++ b/drivers/soc/fsl/qe/qe.c
> @@ -147,7 +147,7 @@ EXPORT_SYMBOL(qe_issue_cmd);
> * memory mapped space.
> * The BRG clock is the QE clock divided by 2.
> * It was set up long ago during the initial boot phase and is
> - * is given to us.
> + * given to us.
> * Baud rate clocks are zero-based in the driver code (as that maps
> * to port numbers). Documentation uses 1-based numbering.
> */
> @@ -421,7 +421,7 @@ static void qe_upload_microcode(const void *base,
>
> for (i = 0; i < be32_to_cpu(ucode->count); i++)
> iowrite32be(be32_to_cpu(code[i]), &qe_immr->iram.idata);
> -
> +
> /* Set I-RAM Ready Register */
> iowrite32be(QE_IRAM_READY, &qe_immr->iram.iready);
> }
> --
> 2.34.1
>
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS f1aa0e47c29268776205698f2453dc07fab49855
From: kernel test robot @ 2022-01-07 2:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: f1aa0e47c29268776205698f2453dc07fab49855 powerpc/xmon: Dump XIVE information for online-only processors.
elapsed time: 721m
configs tested: 122
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm allyesconfig
arm allmodconfig
arm64 defconfig
i386 randconfig-c001-20220106
s390 zfcpdump_defconfig
arm eseries_pxa_defconfig
powerpc adder875_defconfig
sh sh7785lcr_defconfig
powerpc klondike_defconfig
m68k atari_defconfig
m68k multi_defconfig
sh sh7763rdp_defconfig
sh shmin_defconfig
sh se7705_defconfig
powerpc tqm8xx_defconfig
sh se7206_defconfig
powerpc64 alldefconfig
arc axs101_defconfig
powerpc taishan_defconfig
sh edosk7705_defconfig
sh r7780mp_defconfig
mips loongson3_defconfig
ia64 gensparse_defconfig
openrisc or1ksim_defconfig
xtensa cadence_csp_defconfig
sh ap325rxa_defconfig
powerpc ep88xc_defconfig
m68k m5407c3_defconfig
mips cobalt_defconfig
sh se7721_defconfig
mips gpr_defconfig
arm randconfig-c002-20220106
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a012-20220106
x86_64 randconfig-a015-20220106
x86_64 randconfig-a014-20220106
x86_64 randconfig-a013-20220106
x86_64 randconfig-a011-20220106
x86_64 randconfig-a016-20220106
i386 randconfig-a012-20220106
i386 randconfig-a016-20220106
i386 randconfig-a014-20220106
i386 randconfig-a015-20220106
i386 randconfig-a011-20220106
i386 randconfig-a013-20220106
s390 randconfig-r044-20220106
arc randconfig-r043-20220106
riscv randconfig-r042-20220106
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
mips randconfig-c004-20220106
arm randconfig-c002-20220106
i386 randconfig-c001-20220106
riscv randconfig-c006-20220106
powerpc randconfig-c003-20220106
x86_64 randconfig-c007-20220106
s390 randconfig-c005-20220106
arm colibri_pxa300_defconfig
mips lemote2f_defconfig
mips tb0219_defconfig
powerpc xes_mpc85xx_defconfig
s390 alldefconfig
mips ip28_defconfig
mips bmips_stb_defconfig
i386 randconfig-a003-20220106
i386 randconfig-a005-20220106
i386 randconfig-a004-20220106
i386 randconfig-a006-20220106
i386 randconfig-a002-20220106
i386 randconfig-a001-20220106
x86_64 randconfig-a005-20220106
x86_64 randconfig-a001-20220106
x86_64 randconfig-a004-20220106
x86_64 randconfig-a006-20220106
x86_64 randconfig-a002-20220106
x86_64 randconfig-a003-20220106
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ 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