* [RFC PATCH 05/12] arm/sdei: add support to trigger event by GIC interrupt ID
From: Heyi Guo @ 2019-09-24 15:21 UTC (permalink / raw)
To: qemu-arm, qemu-devel, linux-arm-kernel, kvmarm
Cc: Mark Rutland, Peter Maydell, Marc Zyngier, James Morse, Heyi Guo,
wanghaibin.wang, Dave Martin
In-Reply-To: <1569338511-3572-1-git-send-email-guoheyi@huawei.com>
Add an external interface to trigger an SDEI event bound to an
interrupt by providing GIC interrupt ID.
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
---
target/arm/sdei.c | 38 ++++++++++++++++++++++++++++++++++++++
target/arm/sdei.h | 7 +++++++
2 files changed, 45 insertions(+)
diff --git a/target/arm/sdei.c b/target/arm/sdei.c
index f9a1208..088ed76 100644
--- a/target/arm/sdei.c
+++ b/target/arm/sdei.c
@@ -453,6 +453,29 @@ static int64_t sdei_version(QemuSDEState *s, CPUState *cs, struct kvm_run *run)
(0ULL << SDEI_VERSION_MINOR_SHIFT);
}
+static bool inject_event(QemuSDEState *s, CPUState *cs,
+ int32_t event, int irq)
+{
+ QemuSDE *sde;
+
+ if (event < 0) {
+ return false;
+ }
+ sde = get_sde_no_check(s, event, cs);
+ if (sde->event_id == SDEI_INVALID_EVENT_ID) {
+ put_sde(sde, cs);
+ return false;
+ }
+ if (irq > 0 && sde->prop->interrupt != irq) {
+ /* Someone unbinds the interrupt! */
+ put_sde(sde, cs);
+ return false;
+ }
+ sde->pending = true;
+ dispatch_single(s, sde, cs);
+ return true;
+}
+
static int64_t unregister_single_sde(QemuSDEState *s, int32_t event,
CPUState *cs, bool force)
{
@@ -1033,6 +1056,21 @@ void sdei_handle_request(CPUState *cs, struct kvm_run *run)
}
}
+bool trigger_sdei_by_irq(int cpu, int irq)
+{
+ QemuSDEState *s = sde_state;
+
+ if (!s || irq >= ARRAY_SIZE(s->irq_map)) {
+ return false;
+ }
+
+ if (s->irq_map[irq] == SDEI_INVALID_EVENT_ID) {
+ return false;
+ }
+
+ return inject_event(s, arm_get_cpu_by_id(cpu), s->irq_map[irq], irq);
+}
+
static void qemu_shared_sde_init(QemuSDEState *s)
{
int i;
diff --git a/target/arm/sdei.h b/target/arm/sdei.h
index a69a0e4..a61e788 100644
--- a/target/arm/sdei.h
+++ b/target/arm/sdei.h
@@ -31,4 +31,11 @@
void sdei_handle_request(CPUState *cs, struct kvm_run *run);
+/*
+ * Trigger an SDEI event bound to an interrupt.
+ * Return true if event has been triggered successfully.
+ * Return false if event has not been triggered for some reason.
+ */
+bool trigger_sdei_by_irq(int cpu, int irq);
+
#endif
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 01/12] linux-headers: import arm_sdei.h
From: Heyi Guo @ 2019-09-24 15:21 UTC (permalink / raw)
To: qemu-arm, qemu-devel, linux-arm-kernel, kvmarm
Cc: Mark Rutland, Peter Maydell, Michael S. Tsirkin, Marc Zyngier,
Cornelia Huck, James Morse, Paolo Bonzini, Heyi Guo,
wanghaibin.wang, Dave Martin
In-Reply-To: <1569338511-3572-1-git-send-email-guoheyi@huawei.com>
Import Linux header file include/uapi/linux/arm_sdei.h from kernel
v5.3 release.
This is to prepare for qemu SDEI emulation.
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
---
| 73 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
create mode 100644 linux-headers/linux/arm_sdei.h
--git a/linux-headers/linux/arm_sdei.h b/linux-headers/linux/arm_sdei.h
new file mode 100644
index 0000000..af0630b
--- /dev/null
+++ b/linux-headers/linux/arm_sdei.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* Copyright (C) 2017 Arm Ltd. */
+#ifndef _UAPI_LINUX_ARM_SDEI_H
+#define _UAPI_LINUX_ARM_SDEI_H
+
+#define SDEI_1_0_FN_BASE 0xC4000020
+#define SDEI_1_0_MASK 0xFFFFFFE0
+#define SDEI_1_0_FN(n) (SDEI_1_0_FN_BASE + (n))
+
+#define SDEI_1_0_FN_SDEI_VERSION SDEI_1_0_FN(0x00)
+#define SDEI_1_0_FN_SDEI_EVENT_REGISTER SDEI_1_0_FN(0x01)
+#define SDEI_1_0_FN_SDEI_EVENT_ENABLE SDEI_1_0_FN(0x02)
+#define SDEI_1_0_FN_SDEI_EVENT_DISABLE SDEI_1_0_FN(0x03)
+#define SDEI_1_0_FN_SDEI_EVENT_CONTEXT SDEI_1_0_FN(0x04)
+#define SDEI_1_0_FN_SDEI_EVENT_COMPLETE SDEI_1_0_FN(0x05)
+#define SDEI_1_0_FN_SDEI_EVENT_COMPLETE_AND_RESUME SDEI_1_0_FN(0x06)
+#define SDEI_1_0_FN_SDEI_EVENT_UNREGISTER SDEI_1_0_FN(0x07)
+#define SDEI_1_0_FN_SDEI_EVENT_STATUS SDEI_1_0_FN(0x08)
+#define SDEI_1_0_FN_SDEI_EVENT_GET_INFO SDEI_1_0_FN(0x09)
+#define SDEI_1_0_FN_SDEI_EVENT_ROUTING_SET SDEI_1_0_FN(0x0A)
+#define SDEI_1_0_FN_SDEI_PE_MASK SDEI_1_0_FN(0x0B)
+#define SDEI_1_0_FN_SDEI_PE_UNMASK SDEI_1_0_FN(0x0C)
+#define SDEI_1_0_FN_SDEI_INTERRUPT_BIND SDEI_1_0_FN(0x0D)
+#define SDEI_1_0_FN_SDEI_INTERRUPT_RELEASE SDEI_1_0_FN(0x0E)
+#define SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI_1_0_FN(0x11)
+#define SDEI_1_0_FN_SDEI_SHARED_RESET SDEI_1_0_FN(0x12)
+
+#define SDEI_VERSION_MAJOR_SHIFT 48
+#define SDEI_VERSION_MAJOR_MASK 0x7fff
+#define SDEI_VERSION_MINOR_SHIFT 32
+#define SDEI_VERSION_MINOR_MASK 0xffff
+#define SDEI_VERSION_VENDOR_SHIFT 0
+#define SDEI_VERSION_VENDOR_MASK 0xffffffff
+
+#define SDEI_VERSION_MAJOR(x) (x>>SDEI_VERSION_MAJOR_SHIFT & SDEI_VERSION_MAJOR_MASK)
+#define SDEI_VERSION_MINOR(x) (x>>SDEI_VERSION_MINOR_SHIFT & SDEI_VERSION_MINOR_MASK)
+#define SDEI_VERSION_VENDOR(x) (x>>SDEI_VERSION_VENDOR_SHIFT & SDEI_VERSION_VENDOR_MASK)
+
+/* SDEI return values */
+#define SDEI_SUCCESS 0
+#define SDEI_NOT_SUPPORTED -1
+#define SDEI_INVALID_PARAMETERS -2
+#define SDEI_DENIED -3
+#define SDEI_PENDING -5
+#define SDEI_OUT_OF_RESOURCE -10
+
+/* EVENT_REGISTER flags */
+#define SDEI_EVENT_REGISTER_RM_ANY 0
+#define SDEI_EVENT_REGISTER_RM_PE 1
+
+/* EVENT_STATUS return value bits */
+#define SDEI_EVENT_STATUS_RUNNING 2
+#define SDEI_EVENT_STATUS_ENABLED 1
+#define SDEI_EVENT_STATUS_REGISTERED 0
+
+/* EVENT_COMPLETE status values */
+#define SDEI_EV_HANDLED 0
+#define SDEI_EV_FAILED 1
+
+/* GET_INFO values */
+#define SDEI_EVENT_INFO_EV_TYPE 0
+#define SDEI_EVENT_INFO_EV_SIGNALED 1
+#define SDEI_EVENT_INFO_EV_PRIORITY 2
+#define SDEI_EVENT_INFO_EV_ROUTING_MODE 3
+#define SDEI_EVENT_INFO_EV_ROUTING_AFF 4
+
+/* and their results */
+#define SDEI_EVENT_TYPE_PRIVATE 0
+#define SDEI_EVENT_TYPE_SHARED 1
+#define SDEI_EVENT_PRIORITY_NORMAL 0
+#define SDEI_EVENT_PRIORITY_CRITICAL 1
+
+#endif /* _UAPI_LINUX_ARM_SDEI_H */
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 02/12] arm/sdei: add virtual device framework
From: Heyi Guo @ 2019-09-24 15:21 UTC (permalink / raw)
To: qemu-arm, qemu-devel, linux-arm-kernel, kvmarm
Cc: Mark Rutland, Peter Maydell, James Morse, Marc Zyngier,
Jingyi Wang, Heyi Guo, wanghaibin.wang, Dave Martin
In-Reply-To: <1569338511-3572-1-git-send-email-guoheyi@huawei.com>
SDEI is useful to emulate NMI on arm64 platforms. To support SDEI in
virtual machine with KVM enabled, we choose to implement SDEI
interfaces in qemu. It is targeted for KVM mode only, for the full
user space emulation can also emulate secure world and have ARM
Trusted Firmware to run on emulated EL3.
- We create a logical SDEI device to hold the states of SDEI services,
to support VM migration.
- Only one SDEI virtual device is allowed in the whole VM to provide
SDEI services.
- We create struct QemuSDE to hold states of each SDEI event, and
private events with the same ID on different CPUs have their own
QemuSDE instance.
- We create struct QemuSDEProp to hold properties of each SDEI event,
so all private instances with the same ID will pointed to the same
QemuSDEProp.
- We create struct QemuSDECpu to hold CPU/PE states, including the
interrupted CPU context.
- Slot numbers for private and shared event are fixed, for guests
cannot request more interrupt binds than BIND_SLOTS in SDEI_FEATURES
call.
- The first PRIVATE_SLOT_COUNT slots in property array are for private
events, and the next SHARED_SLOT_COUNT slots are for shared events.
- We use property slot index as lower bit for each allocated event
number, so that we can get property easily from valid input event
number, as well as the QemuSDE instance.
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Signed-off-by: Jingyi Wang <wangjingyi11@huawei.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
---
target/arm/Makefile.objs | 1 +
target/arm/sdei.c | 351 +++++++++++++++++++++++++++++++++++++++++++++++
target/arm/sdei_int.h | 106 ++++++++++++++
3 files changed, 458 insertions(+)
create mode 100644 target/arm/sdei.c
create mode 100644 target/arm/sdei_int.h
diff --git a/target/arm/Makefile.objs b/target/arm/Makefile.objs
index cf26c16..674109d 100644
--- a/target/arm/Makefile.objs
+++ b/target/arm/Makefile.objs
@@ -7,6 +7,7 @@ obj-$(CONFIG_SOFTMMU) += machine.o arch_dump.o monitor.o
obj-$(CONFIG_SOFTMMU) += arm-powerctl.o
obj-$(CONFIG_KVM) += kvm.o
+obj-$(CONFIG_KVM) += sdei.o
obj-$(call land,$(CONFIG_KVM),$(call lnot,$(TARGET_AARCH64))) += kvm32.o
obj-$(call land,$(CONFIG_KVM),$(TARGET_AARCH64)) += kvm64.o
obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
diff --git a/target/arm/sdei.c b/target/arm/sdei.c
new file mode 100644
index 0000000..7f12d69
--- /dev/null
+++ b/target/arm/sdei.c
@@ -0,0 +1,351 @@
+/*
+ * ARM SDEI emulation for ARM64 virtual machine with KVM
+ *
+ * Copyright (c) 2019 HUAWEI TECHNOLOGIES CO., LTD.
+ *
+ * Authors:
+ * Heyi Guo <guoheyi@huawei.com>
+ * Jingyi Wang <wangjingyi11@huawei.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "arm-powerctl.h"
+#include "qemu/timer.h"
+#include "sysemu/kvm.h"
+#include "sysemu/kvm_int.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/reset.h"
+#include "qemu/error-report.h"
+#include "sdei_int.h"
+#include "internals.h"
+#include "hw/boards.h"
+#include "hw/intc/arm_gicv3.h"
+#include "hw/intc/arm_gic.h"
+#include "hw/irq.h"
+#include "hw/sysbus.h"
+#include "migration/vmstate.h"
+#include "qom/object.h"
+
+#define TYPE_QEMU_SDEI "qemu_sdei"
+#define QEMU_SDEI(obj) OBJECT_CHECK(QemuSDEState, (obj), TYPE_QEMU_SDEI)
+
+static QemuSDEState *sde_state;
+
+static void qemu_sde_prop_init(QemuSDEState *s)
+{
+ QemuSDEProp *sde_props = s->sde_props_state;
+ int i;
+ for (i = 0; i < ARRAY_SIZE(s->sde_props_state); i++) {
+ sde_props[i].event_id = SDEI_INVALID_EVENT_ID;
+ sde_props[i].interrupt = SDEI_INVALID_INTERRUPT;
+ sde_props[i].sde_index = i >= PRIVATE_SLOT_COUNT ?
+ i - PRIVATE_SLOT_COUNT : i;
+
+ qemu_mutex_init(&(sde_props[i].lock));
+ sde_props[i].refcount = 0;
+ }
+ sde_props[0].event_id = SDEI_STD_EVT_SOFTWARE_SIGNAL;
+ sde_props[0].interrupt = SDEI_INVALID_INTERRUPT;
+ sde_props[0].is_shared = false;
+ sde_props[0].is_critical = false;
+
+ for (i = 0; i < ARRAY_SIZE(s->irq_map); i++) {
+ s->irq_map[i] = SDEI_INVALID_EVENT_ID;
+ }
+
+ qemu_mutex_init(&s->sdei_interrupt_bind_lock);
+}
+
+static void qemu_sde_cpu_init(QemuSDEState *s)
+{
+ int i;
+ QemuSDECpu *sde_cpus;
+
+ s->sdei_max_cpus = current_machine->smp.max_cpus;
+ s->sde_cpus = g_new0(QemuSDECpu, s->sdei_max_cpus);
+ sde_cpus = s->sde_cpus;
+ for (i = 0; i < s->sdei_max_cpus; i++) {
+ sde_cpus[i].masked = true;
+ sde_cpus[i].critical_running_event = SDEI_INVALID_EVENT_ID;
+ sde_cpus[i].normal_running_event = SDEI_INVALID_EVENT_ID;
+ }
+}
+
+static bool is_valid_event_number(int32_t event)
+{
+ int32_t slot_id;
+
+ if (event < 0 || (event & 0x3F000000)) {
+ return false;
+ }
+
+ slot_id = SDEI_EVENT_TO_SLOT(event);
+ if (slot_id >= PRIVATE_SLOT_COUNT + SHARED_SLOT_COUNT) {
+ return false;
+ }
+
+ return true;
+}
+
+static bool is_valid_event(QemuSDEState *s, int32_t event)
+{
+ if (!is_valid_event_number(event)) {
+ return false;
+ }
+
+ if (s->sde_props_state[SDEI_EVENT_TO_SLOT(event)].event_id != event) {
+ return false;
+ }
+
+ return true;
+}
+
+static QemuSDEProp *get_sde_prop_no_lock(QemuSDEState *s, int32_t event)
+{
+ if (!is_valid_event(s, event)) {
+ return NULL;
+ }
+
+ return &s->sde_props_state[SDEI_EVENT_TO_SLOT(event)];
+}
+
+static void qemu_shared_sde_init(QemuSDEState *s)
+{
+ int i;
+ for (i = 0; i < SHARED_SLOT_COUNT; i++) {
+ QemuSDE *sde;
+ sde = s->shared_sde_array[i];
+ if (!sde) {
+ sde = g_new0(QemuSDE, 1);
+ }
+ sde->event_id = SDEI_INVALID_EVENT_ID;
+ sde->enabled = false;
+ sde->running = false;
+ sde->pending = false;
+ sde->unregister_pending = false;
+ qemu_mutex_init(&sde->lock);
+ s->shared_sde_array[i] = sde;
+ }
+}
+
+static void qemu_private_sde_init(QemuSDEState *s)
+{
+ int i, j;
+ for (i = 0; i < s->sdei_max_cpus; i++) {
+ QemuSDE **array = s->sde_cpus[i].private_sde_array;
+ for (j = 0; j < PRIVATE_SLOT_COUNT; j++) {
+ QemuSDE *sde;
+ sde = array[j];
+ if (!sde) {
+ sde = g_new0(QemuSDE, 1);
+ }
+ sde->event_id = SDEI_INVALID_EVENT_ID;
+ sde->enabled = false;
+ sde->running = false;
+ sde->pending = false;
+ sde->unregister_pending = false;
+ qemu_mutex_init(&sde->lock);
+ array[j] = sde;
+ }
+ }
+}
+
+static void qemu_sde_init(QemuSDEState *s)
+{
+ qemu_sde_prop_init(s);
+ qemu_sde_cpu_init(s);
+
+ qemu_shared_sde_init(s);
+ qemu_private_sde_init(s);
+}
+
+static int qemu_sdei_pre_save(void *opaque)
+{
+ QemuSDEState *s = opaque;
+ QemuSDE **array;
+ int i, j;
+
+ for (i = 0; i < s->sdei_max_cpus; i++) {
+ array = s->sde_cpus[i].private_sde_array;
+ for (j = 0; j < PRIVATE_SLOT_COUNT; j++) {
+ QemuSDE *sde = array[j];
+ if (sde->event_id != SDEI_INVALID_EVENT_ID) {
+ sde->event_id = sde->prop->event_id;
+ sde->cpu_affinity = ARM_CPU(sde->target_cpu)->mp_affinity;
+ }
+ }
+ }
+
+ array = s->shared_sde_array;
+ for (j = 0; j < SHARED_SLOT_COUNT; j++) {
+ QemuSDE *sde = array[j];
+ if (sde->event_id != SDEI_INVALID_EVENT_ID) {
+ sde->event_id = sde->prop->event_id;
+ sde->cpu_affinity = ARM_CPU(sde->target_cpu)->mp_affinity;
+ }
+ }
+
+ return 0;
+}
+
+
+static int qemu_sdei_post_load(void *opaque, int version_id)
+{
+ QemuSDEState *s = opaque;
+ QemuSDEProp *sde_props = s->sde_props_state;
+ QemuSDE **array;
+ int i, j;
+
+ for (i = 0; i < s->sdei_max_cpus; i++) {
+ array = s->sde_cpus[i].private_sde_array;
+ for (j = 0; j < PRIVATE_SLOT_COUNT; j++) {
+ QemuSDE *sde = array[j];
+ if (sde->event_id != SDEI_INVALID_EVENT_ID) {
+ sde->prop = get_sde_prop_no_lock(s, sde->event_id);
+ sde->target_cpu = arm_get_cpu_by_id(sde->cpu_affinity);
+ }
+ }
+ }
+
+ array = s->shared_sde_array;
+ for (j = 0; j < SHARED_SLOT_COUNT; j++) {
+ QemuSDE *sde = array[j];
+ if (sde->event_id != SDEI_INVALID_EVENT_ID) {
+ sde->prop = get_sde_prop_no_lock(s, sde->event_id);
+ sde->target_cpu = arm_get_cpu_by_id(sde->cpu_affinity);
+ }
+ }
+
+ for (i = 0; i < PRIVATE_SLOT_COUNT + SHARED_SLOT_COUNT; i++) {
+ if (sde_props[i].interrupt != SDEI_INVALID_INTERRUPT) {
+ s->irq_map[sde_props[i].interrupt] = sde_props[i].event_id;
+ }
+ }
+
+ return 0;
+}
+
+static const VMStateDescription vmstate_sdes = {
+ .name = "qemu_sdei/sdes",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_BOOL(enabled, QemuSDE),
+ VMSTATE_BOOL(running, QemuSDE),
+ VMSTATE_BOOL(pending, QemuSDE),
+ VMSTATE_BOOL(unregister_pending, QemuSDE),
+ VMSTATE_UINT64(ep_address, QemuSDE),
+ VMSTATE_UINT64(ep_argument, QemuSDE),
+ VMSTATE_UINT64(routing_mode, QemuSDE),
+ VMSTATE_INT32(event_id, QemuSDE),
+ VMSTATE_UINT64(cpu_affinity, QemuSDE),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static const VMStateDescription vmstate_sde_props = {
+ .name = "qemu_sdei/sde_props",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_INT32(event_id, QemuSDEProp),
+ VMSTATE_INT32(interrupt, QemuSDEProp),
+ VMSTATE_BOOL(is_shared, QemuSDEProp),
+ VMSTATE_BOOL(is_critical, QemuSDEProp),
+ VMSTATE_INT32(sde_index, QemuSDEProp),
+ VMSTATE_INT32(refcount, QemuSDEProp),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static const VMStateDescription vmstate_sde_cpu = {
+ .name = "qemu_sdei/sde_cpu",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_ARRAY_OF_POINTER_TO_STRUCT(private_sde_array, QemuSDECpu,
+ PRIVATE_SLOT_COUNT, 1,
+ vmstate_sdes, QemuSDE),
+ VMSTATE_UINT64_ARRAY(ctx[0].xregs, QemuSDECpu, 18),
+ VMSTATE_UINT64_ARRAY(ctx[1].xregs, QemuSDECpu, 18),
+ VMSTATE_UINT64(ctx[0].pc, QemuSDECpu),
+ VMSTATE_UINT64(ctx[1].pc, QemuSDECpu),
+ VMSTATE_UINT32(ctx[0].pstate, QemuSDECpu),
+ VMSTATE_UINT32(ctx[1].pstate, QemuSDECpu),
+ VMSTATE_INT32(critical_running_event, QemuSDECpu),
+ VMSTATE_INT32(normal_running_event, QemuSDECpu),
+ VMSTATE_BOOL(masked, QemuSDECpu),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static const VMStateDescription vmstate_sde_state = {
+ .name = "qemu_sdei",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .pre_save = qemu_sdei_pre_save,
+ .post_load = qemu_sdei_post_load,
+ .fields = (VMStateField[]) {
+ VMSTATE_STRUCT_ARRAY(sde_props_state, QemuSDEState,
+ PRIVATE_SLOT_COUNT + SHARED_SLOT_COUNT, 1,
+ vmstate_sde_props, QemuSDEProp),
+ VMSTATE_ARRAY_OF_POINTER_TO_STRUCT(shared_sde_array, QemuSDEState,
+ SHARED_SLOT_COUNT, 1,
+ vmstate_sdes, QemuSDE),
+ VMSTATE_STRUCT_VARRAY_POINTER_INT32(sde_cpus, QemuSDEState,
+ sdei_max_cpus,
+ vmstate_sde_cpu, QemuSDECpu),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+
+static void sdei_initfn(Object *obj)
+{
+ QemuSDEState *s = QEMU_SDEI(obj);
+
+ if (sde_state) {
+ error_report("Only one SDEI dispatcher is allowed!");
+ abort();
+ }
+ sde_state = s;
+
+ qemu_sde_init(s);
+}
+
+static void qemu_sde_class_init(ObjectClass *klass, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+
+ dc->desc = "SDEI_QEMU";
+ dc->vmsd = &vmstate_sde_state;
+ dc->user_creatable = true;
+}
+
+static const TypeInfo sde_qemu_info = {
+ .name = TYPE_QEMU_SDEI,
+ .parent = TYPE_DEVICE,
+ .instance_size = sizeof(QemuSDEState),
+ .instance_init = sdei_initfn,
+ .class_init = qemu_sde_class_init,
+};
+
+static void register_types(void)
+{
+ type_register_static(&sde_qemu_info);
+}
+
+type_init(register_types);
diff --git a/target/arm/sdei_int.h b/target/arm/sdei_int.h
new file mode 100644
index 0000000..7f69507
--- /dev/null
+++ b/target/arm/sdei_int.h
@@ -0,0 +1,106 @@
+/*
+ * ARM SDEI emulation internal interfaces
+ *
+ * Copyright (c) 2019 HUAWEI TECHNOLOGIES CO., LTD.
+ *
+ * Authors:
+ * Heyi Guo <guoheyi@huawei.com>
+ * Jingyi Wang <wangjingyi11@huawei.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef QEMU_SDEI_INT_H
+#define QEMU_SDEI_INT_H
+
+#include <linux/kvm.h>
+#include <linux/arm_sdei.h>
+#include <asm-arm64/kvm.h>
+#include "hw/intc/arm_gic_common.h"
+#include "qemu/thread.h"
+
+#define SDEI_STD_EVT_SOFTWARE_SIGNAL 0
+#define SDEI_FEATURE_BIND_SLOTS 0
+#define SDEI_PARAM_MAX 18
+
+#define PRIVATE_SLOT_COUNT 16
+#define PLAT_PRIVATE_SLOT_COUNT 8
+#define SHARED_SLOT_COUNT 32
+#define PLAT_SHARED_SLOT_COUNT 16
+#define SDEI_INVALID_INTERRUPT -1
+#define SDEI_INVALID_EVENT_ID -1
+
+#define SDEI_EVENT_TO_SLOT(event) ((event) & 0xFFFFFF)
+#define SDEI_IS_SHARED_EVENT(event) \
+ (SDEI_EVENT_TO_SLOT(event) >= PRIVATE_SLOT_COUNT)
+
+typedef enum {
+ SDEI_PRIO_NORMAL = 0,
+ SDEI_PRIO_CRITICAL = 1,
+} QemuSDEIPriority;
+
+typedef struct QemuSDEProp {
+ QemuMutex lock;
+ int32_t event_id;
+ int interrupt;
+ bool is_shared;
+ bool is_critical;
+ /* This is the internal index for private or shared SDE */
+ int sde_index;
+ int refcount;
+} QemuSDEProp;
+
+typedef struct QemuSDE {
+ QemuSDEProp *prop;
+ CPUState *target_cpu;
+ QemuMutex lock;
+ bool enabled;
+ bool running;
+ bool pending;
+ bool unregister_pending;
+ uint64_t ep_address;
+ uint64_t ep_argument;
+ uint64_t routing_mode;
+ int32_t event_id;
+ /*
+ * For it is not easy to save the pointer target_cpu during migration, we
+ * add below field to save the corresponding numerical values.
+ */
+ uint64_t cpu_affinity;
+} QemuSDE;
+
+typedef struct QemuSDECpuCtx {
+ uint64_t xregs[18];
+ uint64_t pc;
+ uint32_t pstate;
+} QemuSDECpuCtx;
+
+typedef struct QemuSDECpu {
+ QemuSDE *private_sde_array[PRIVATE_SLOT_COUNT];
+ QemuSDECpuCtx ctx[2];
+ bool masked;
+ int32_t critical_running_event;
+ int32_t normal_running_event;
+} QemuSDECpu;
+
+typedef struct QemuSDEState {
+ DeviceState parent_obj;
+ QemuSDEProp sde_props_state[PRIVATE_SLOT_COUNT + SHARED_SLOT_COUNT];
+ QemuSDECpu *sde_cpus;
+ int sdei_max_cpus;
+ QemuSDE *shared_sde_array[SHARED_SLOT_COUNT];
+ int32_t irq_map[GIC_MAXIRQ];
+ QemuMutex sdei_interrupt_bind_lock;
+} QemuSDEState;
+
+#endif
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 00/12] Add SDEI support for arm64
From: Heyi Guo @ 2019-09-24 15:21 UTC (permalink / raw)
To: qemu-arm, qemu-devel, linux-arm-kernel, kvmarm
Cc: Mark Rutland, Peter Maydell, Marc Zyngier, James Morse, Heyi Guo,
wanghaibin.wang, Dave Martin
As promised, this is the first RFC patch set for arm64 SDEI support.
Key points:
- We propose to only support kvm enabled arm64 virtual machines, for
non-kvm VMs can emulate EL3 and have Trusted Firmware run on it,
which has a builtin SDEI dispatcher.
- New kvm capability KVM_CAP_FORWARD_HYPERCALL is added to probe if
kvm supports forwarding hypercalls, and the capability should be
enabled explicitly. PSCI can be set as exception for backward
compatibility.
- We make the dispatcher as a logical device, to save the states
during migration or save/restore operation; only one instance is
allowed in one VM.
- We use qemu_irq as the bridge for other qemu modules to switch from
irq injection to SDEI event trigger after VM binds the interrupt to
SDEI event. We use qemu_irq_intercept_in() to override qemu_irq
handler with SDEI event trigger, and a new interface
qemu_irq_remove_intercept() is added to restore the handler to
default one (i.e. ARM GIC).
More details are in the commit message of each patch.
Basic tests are done by emulating a watchdog timer and triggering SDEI
event in every 10s.
As this is the first rough RFC, please focus on the interfaces and
framework first. We can refine the code for several rounds after the
big things have been determined.
Please give your comments and suggestions.
Thanks,
HG
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Heyi Guo (12):
linux-headers: import arm_sdei.h
arm/sdei: add virtual device framework
arm/sdei: add support to handle SDEI requests from guest
arm/sdei: add system reset callback
arm/sdei: add support to trigger event by GIC interrupt ID
core/irq: add qemu_irq_remove_intercept interface
arm/sdei: override qemu_irq handler when binding interrupt
arm/sdei: add support to register interrupt bind notifier
linux-headers/kvm.h: add capability to forward hypercall
arm/sdei: check KVM cap and enable SDEI
arm/kvm: handle guest exit of hypercall
virt/acpi: add SDEI table if SDEI is enabled
hw/arm/virt-acpi-build.c | 16 +
hw/core/irq.c | 11 +
include/hw/acpi/acpi-defs.h | 5 +
include/hw/irq.h | 8 +-
linux-headers/linux/arm_sdei.h | 73 ++
linux-headers/linux/kvm.h | 3 +
target/arm/Makefile.objs | 1 +
target/arm/kvm.c | 17 +
target/arm/sdei.c | 1518 ++++++++++++++++++++++++++++++++++++++++
target/arm/sdei.h | 60 ++
target/arm/sdei_int.h | 109 +++
11 files changed, 1819 insertions(+), 2 deletions(-)
create mode 100644 linux-headers/linux/arm_sdei.h
create mode 100644 target/arm/sdei.c
create mode 100644 target/arm/sdei.h
create mode 100644 target/arm/sdei_int.h
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 2/2] kvm/arm64: expose hypercall_forwarding capability
From: Heyi Guo @ 2019-09-24 15:20 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel, kvm, qemu-arm
Cc: Mark Rutland, Peter Maydell, Suzuki K Poulose, Marc Zyngier,
Catalin Marinas, Radim Krčmář, James Morse,
Paolo Bonzini, Heyi Guo, wanghaibin.wang, Will Deacon,
Dave Martin, Julien Thierry
In-Reply-To: <1569338454-26202-1-git-send-email-guoheyi@huawei.com>
Add new KVM capability "KVM_CAP_FORWARD_HYPERCALL" for user space to
probe whether KVM supports forwarding hypercall.
The capability should be enabled by user space explicitly, for we
don't want user space application to deal with unexpected hypercall
exits. We also use an additional argument to pass exception bit mask,
to request KVM to forward all hypercalls except the classes specified
in the bit mask.
Currently only PSCI can be set as exception, so that we can still keep
consistent with the old PSCI processing flow.
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
---
arch/arm64/kvm/reset.c | 25 +++++++++++++++++++++++++
include/uapi/linux/kvm.h | 3 +++
2 files changed, 28 insertions(+)
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index f4a8ae9..2201b62 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -95,6 +95,9 @@ int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = has_vhe() && system_supports_address_auth() &&
system_supports_generic_auth();
break;
+ case KVM_CAP_FORWARD_HYPERCALL:
+ r = 1;
+ break;
default:
r = 0;
}
@@ -102,6 +105,28 @@ int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext)
return r;
}
+int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
+ struct kvm_enable_cap *cap)
+{
+ if (cap->flags)
+ return -EINVAL;
+
+ switch (cap->cap) {
+ case KVM_CAP_FORWARD_HYPERCALL: {
+ __u64 exclude_flags = cap->args[0];
+ /* Only support excluding PSCI right now */
+ if (exclude_flags & ~KVM_CAP_FORWARD_HYPERCALL_EXCL_PSCI)
+ return -EINVAL;
+ kvm->arch.hypercall_forward = true;
+ if (exclude_flags & KVM_CAP_FORWARD_HYPERCALL_EXCL_PSCI)
+ kvm->arch.hypercall_excl_psci = true;
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
unsigned int kvm_sve_max_vl;
int kvm_arm_init_sve(void)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 5e3f12d..e3e5787 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -711,6 +711,8 @@ struct kvm_enable_cap {
__u8 pad[64];
};
+#define KVM_CAP_FORWARD_HYPERCALL_EXCL_PSCI (1 << 0)
+
/* for KVM_PPC_GET_PVINFO */
#define KVM_PPC_PVINFO_FLAGS_EV_IDLE (1<<0)
@@ -996,6 +998,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
#define KVM_CAP_ARM_PTRAUTH_GENERIC 172
#define KVM_CAP_PMU_EVENT_FILTER 173
+#define KVM_CAP_FORWARD_HYPERCALL 174
#ifdef KVM_CAP_IRQ_ROUTING
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 1/2] kvm/arm: add capability to forward hypercall to user space
From: Heyi Guo @ 2019-09-24 15:20 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel, kvm, qemu-arm
Cc: Mark Rutland, Peter Maydell, Suzuki K Poulose, Marc Zyngier,
Catalin Marinas, Russell King, James Morse, Heyi Guo,
wanghaibin.wang, Will Deacon, Dave Martin, Julien Thierry
In-Reply-To: <1569338454-26202-1-git-send-email-guoheyi@huawei.com>
As more SMC/HVC usages emerge on arm64 platforms, like SDEI, it makes
sense for kvm to have the capability of forwarding such calls to user
space for further emulation.
We reuse the existing term "hypercall" for SMC/HVC, as well as the
hypercall structure in kvm_run to exchange arguments and return
values. The definition on arm64 is as below:
exit_reason: KVM_EXIT_HYPERCALL
Input:
nr: the immediate value of SMC/HVC calls; not really used today.
args[6]: x0..x5 (This is not fully conform with SMCCC which requires
x6 as argument as well, but use space can use GET_ONE_REG
ioctl for such rare case).
Return:
args[0..3]: x0..x3 as defined in SMCCC. We need to extract
args[0..3] and write them to x0..x3 when hypercall exit
returns.
Flag hypercall_forward is added to turn on/off hypercall forwarding
and the default is false. Another flag hypercall_excl_psci is to
exclude PSCI from forwarding for backward compatible, and it only
makes sense to check its value when hypercall_forward is enabled.
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
CC: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm/include/asm/kvm_host.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 5 +++++
include/kvm/arm_psci.h | 1 +
virt/kvm/arm/arm.c | 2 ++
virt/kvm/arm/psci.c | 30 ++++++++++++++++++++++++++++--
5 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 8a37c8e..68ccaf0 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -76,6 +76,11 @@ struct kvm_arch {
/* Mandated version of PSCI */
u32 psci_version;
+
+ /* Flags to control hypercall forwarding to userspace */
+ bool hypercall_forward;
+ /* Exclude PSCI from hypercall forwarding and let kvm to handle it */
+ bool hypercall_excl_psci;
};
#define KVM_NR_MEM_OBJS 40
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index f656169..e47ac25 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -83,6 +83,11 @@ struct kvm_arch {
/* Mandated version of PSCI */
u32 psci_version;
+
+ /* Flags to control hypercall forwarding to userspace */
+ bool hypercall_forward;
+ /* Exclude PSCI from hypercall forwarding and let kvm to handle it */
+ bool hypercall_excl_psci;
};
#define KVM_NR_MEM_OBJS 40
diff --git a/include/kvm/arm_psci.h b/include/kvm/arm_psci.h
index 632e78b..9c9a2dc 100644
--- a/include/kvm/arm_psci.h
+++ b/include/kvm/arm_psci.h
@@ -48,5 +48,6 @@ static inline int kvm_psci_version(struct kvm_vcpu *vcpu, struct kvm *kvm)
int kvm_arm_copy_fw_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+void kvm_handle_hypercall_return(struct kvm_vcpu *vcpu, struct kvm_run *run);
#endif /* __KVM_ARM_PSCI_H__ */
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 35a0698..2f4ca21 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -673,6 +673,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
ret = kvm_handle_mmio_return(vcpu, vcpu->run);
if (ret)
return ret;
+ } else if (run->exit_reason == KVM_EXIT_HYPERCALL) {
+ kvm_handle_hypercall_return(vcpu, vcpu->run);
}
if (run->immediate_exit)
diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c
index 87927f7..7e1f735 100644
--- a/virt/kvm/arm/psci.c
+++ b/virt/kvm/arm/psci.c
@@ -389,6 +389,7 @@ static int kvm_psci_call(struct kvm_vcpu *vcpu)
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
{
+ struct kvm *kvm = vcpu->kvm;
u32 func_id = smccc_get_function(vcpu);
u32 val = SMCCC_RET_NOT_SUPPORTED;
u32 feature;
@@ -428,8 +429,27 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
break;
}
break;
- default:
- return kvm_psci_call(vcpu);
+ default: {
+ if (!kvm->arch.hypercall_forward ||
+ kvm->arch.hypercall_excl_psci) {
+ u32 id = func_id & ~PSCI_0_2_64BIT;
+
+ if (id >= PSCI_0_2_FN_BASE && id <= PSCI_0_2_FN(0x1f))
+ return kvm_psci_call(vcpu);
+ }
+
+ if (kvm->arch.hypercall_forward) {
+ /* Exit to user space to process */
+ vcpu->run->exit_reason = KVM_EXIT_HYPERCALL;
+ vcpu->run->hypercall.nr = kvm_vcpu_get_hsr(vcpu) &
+ ESR_ELx_ISS_MASK;
+ vcpu->run->hypercall.args[0] = func_id;
+ vcpu->run->hypercall.args[1] = smccc_get_arg1(vcpu);
+ vcpu->run->hypercall.args[2] = smccc_get_arg2(vcpu);
+ vcpu->run->hypercall.args[3] = smccc_get_arg3(vcpu);
+ return 0;
+ }
+ }
}
smccc_set_retval(vcpu, val, 0, 0, 0);
@@ -603,3 +623,9 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
return -EINVAL;
}
+
+void kvm_handle_hypercall_return(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ smccc_set_retval(vcpu, run->hypercall.args[0], run->hypercall.args[1],
+ run->hypercall.args[2], run->hypercall.args[3]);
+}
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH 0/2] Add virtual SDEI support for arm64
From: Heyi Guo @ 2019-09-24 15:20 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel, kvm, qemu-arm
Cc: Mark Rutland, Peter Maydell, Marc Zyngier, James Morse, Heyi Guo,
wanghaibin.wang, Dave Martin
As promised, this is the first RFC patch set for arm64 virtual SDEI
support.
New kvm capability KVM_CAP_FORWARD_HYPERCALL is added to probe if kvm
supports forwarding hypercalls, and the capability should be enabled
explicitly. PSCI can be set as exception for backward compatibility.
We reuse the existing term "hypercall" for SMC/HVC, as well as the
hypercall structure in kvm_run to exchange arguments and return
values. The definition on arm64 is as below:
exit_reason: KVM_EXIT_HYPERCALL
Input:
nr: the immediate value of SMC/HVC calls; not really used today.
args[6]: x0..x5 (This is not fully conform with SMCCC which requires
x6 as argument as well, but use space can use GET_ONE_REG
ioctl for such rare case).
Return:
args[0..3]: x0..x3 as defined in SMCCC. We need to extract
args[0..3] and write them to x0..x3 when hypercall exit
returns.
And there is a corresponding patch set for qemu.
Please give your comments and suggestions.
Thanks,
HG
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Heyi Guo (2):
kvm/arm: add capability to forward hypercall to user space
kvm/arm64: expose hypercall_forwarding capability
arch/arm/include/asm/kvm_host.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 5 +++++
arch/arm64/kvm/reset.c | 25 +++++++++++++++++++++++++
include/kvm/arm_psci.h | 1 +
include/uapi/linux/kvm.h | 3 +++
virt/kvm/arm/arm.c | 2 ++
virt/kvm/arm/psci.c | 30 ++++++++++++++++++++++++++++--
7 files changed, 69 insertions(+), 2 deletions(-)
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 0/6] mm / virtio: Provide support for unused page reporting
From: Alexander Duyck @ 2019-09-24 15:20 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
lcapitulino, linux-mm, Alexander Duyck, Andrea Arcangeli,
virtio-dev, Michael S. Tsirkin, Matthew Wilcox, Wang, Wei W,
Vlastimil Babka, Rik van Riel, Dan Williams, linux-arm-kernel,
Oscar Salvador, Nitesh Narayan Lal, Konrad Rzeszutek Wilk,
Dave Hansen, LKML, Paolo Bonzini, Andrew Morton, Mel Gorman
In-Reply-To: <20190924142342.GX23050@dhcp22.suse.cz>
On Tue, Sep 24, 2019 at 7:23 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Wed 18-09-19 10:52:25, Alexander Duyck wrote:
> [...]
> > In order to try and keep the time needed to find a non-reported page to
> > a minimum we maintain a "reported_boundary" pointer. This pointer is used
> > by the get_unreported_pages iterator to determine at what point it should
> > resume searching for non-reported pages. In order to guarantee pages do
> > not get past the scan I have modified add_to_free_list_tail so that it
> > will not insert pages behind the reported_boundary.
> >
> > If another process needs to perform a massive manipulation of the free
> > list, such as compaction, it can either reset a given individual boundary
> > which will push the boundary back to the list_head, or it can clear the
> > bit indicating the zone is actively processing which will result in the
> > reporting process resetting all of the boundaries for a given zone.
>
> Is this any different from the previous version? The last review
> feedback (both from me and Mel) was that we are not happy to have an
> externally imposed constrains on how the page allocator is supposed to
> maintain its free lists.
The main change for v10 versus v9 is that I allow the page reporting
boundary to be overridden. Specifically there are two approaches that
can be taken.
The first is to simply reset the iterator for whatever list is
updated. What this will do is reset the iterator back to list_head and
then you can do whatever you want with that specific list.
The other option is to simply clear the ZONE_PAGE_REPORTING_ACTIVE
bit. That will essentially notify the page reporting code that any/all
hints that were recorded have been discarded and that it needs to
start over.
All I am trying to do with this approach is reduce the work. Without
doing this the code has to walk the entire free page list for the
higher orders every iteration and that will not be cheap. Admittedly
it is a bit more invasive than the cut/splice logic used in compaction
which is taking the pages it has already processed and moving them to
the other end of the list. However, I have reduced things so that we
only really are limiting where add_to_free_list_tail can place pages,
and we are having to check/push back the boundaries if a reported page
is removed from a free_list.
> If this is really the only way to go forward then I would like to hear
> very convincing arguments about other approaches not being feasible.
> There are none in this cover letter unfortunately. This will be really a
> hard sell without them.
So I had considered several different approaches.
What I started out with was logic that was performing the hinting as a
part of the architecture specific arch_free_page call. It worked but
had performance issues as we were generating a hint per page freed
which has fairly high overhead.
The approach Nitesh has been using is to try and maintain a separate
bitmap of "dirty" pages that have recently been freed. There are a few
problems I saw with that approach. First is the fact that it becomes
lossy in that pages could be reallocated out while we are waiting for
the iterator to come through and process the page. This results in
there being a greater amount of work as we have to hunt and peck for
the pages, as such the zone lock has to be freed and reacquired often
which slows this approach down further. Secondly there is the
management of the bitmap itself and sparse memory which would likely
necessitate doing something similar to pageblock_flags on order to
support possible gaps in the zones.
I had considered trying to maintain a separate list entirely and have
the free pages placed there. However that was more invasive then this
solution. In addition modifying the free_list/free_area in any way is
problematic as it can result in the zone lock falling into the same
cacheline as the highest order free_area.
Ultimately what I settled on was the approach we have now where adding
a page to the head of the free_list is unchanged, adding a page to the
tail requires a check to see if the iterator is currently walking the
list, and removing the page requires pushing back the iterator if the
page is at the top of the reported list. I was trying to keep the
amount of code that would have to be touched in the non-reported case
to a minimum. With this we have to test for a bit in the zone flags if
adding to tail, and we have to test for a bit in the page on a
move/del from the freelist. So for the most common free/alloc cases we
would only have the impact of the one additional page flag check.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [alsa-devel] Propagating audio properties along the audio path
From: Charles Keepax @ 2019-09-24 14:42 UTC (permalink / raw)
To: Marc Gonzalez
Cc: alsa-devel, Mark Brown, Takashi Iwai, Linux ARM, Liam Girdwood
In-Reply-To: <0a1bd89e-c6b7-d9ce-dac2-fa324e42b31d@free.fr>
On Tue, Sep 24, 2019 at 04:26:20PM +0200, Marc Gonzalez wrote:
> On 24/09/2019 15:52, Charles Keepax wrote:
>
> > In general the ALSA framework doesn't really allow for stream
> > params to change whilst the stream is active. Doing so is
> > also normally very hard for the types of hardware usually
> > involved. For example changing the clocks on a running I2S bus,
> > very difficult to get both ends to pick up those changes at
> > exactly the correct sample. Some newer buses like soundwire
> > have more support for things like this were the ends of the
> > link can synchronise changes but even there that is normally
> > used for adding/removing streams from the bus, not reconfiguring
> > a running stream.
>
> This jives with what "filt3r" wrote on #alsa-soc
>
> "at one point we were just closing the stream (somehow) if we detected
> a change in e.g. sample-rate, so the user-space application would fail
> on snd_pcm_readi()"
>
> snd_pcm_stop(p_spdif->capture_stream, SNDRV_PCM_STATE_DISCONNECTED);
>
Ah ok yeah that seems like a pretty good option to me thus
forcing user-space to re-open at the new params.
> > In your case above I would imagine the system would probably be
> > setup where the DSP handles the conversion between the params
> > requested from the receiver and those requested by user-space.
> > One of the intentions of DPCM was to allow the backend
> > (DSP-receiver here) to have different params to the frontend
> > (DSP-userspace here). Although as you note you still probably
> > need to add something to propagate those changes to the DSP. What
> > form does the physical link between the receiver and the DSP
> > take?
>
> The setup looks like this:
>
> A = Some kind of audio source, typically a TV or game console
> B = The arm64 SoC, equipped with some nice speakers
>
> HDMI
> A ------> B
>
> If we look inside B, we actually have
> B1 = an eARC receiver (input = HDMI, output = I2S)
> B2 = an audio DSP (input = I2S, output = speakers)
>
> I2S ?
> B1 -----> B2 -----> speakers
>
> To answer your question, B1 and B2 are connected via I2S.
>
As yeah reconfiguring the I2S whilst it is running would be a
terrifying prospect.
Thanks,
Charles
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFCv4 3/7] dt-bindings: devfreq: imx: Describe interconnect properties
From: Leonard Crestez @ 2019-09-24 14:39 UTC (permalink / raw)
To: Rob Herring, Georgi Djakov
Cc: Mark Rutland, Artur Świgoń,
linux-arm-kernel@lists.infradead.org, Saravana Kannan,
linux-pm@vger.kernel.org, Stephen Boyd, Viresh Kumar,
Michael Turquette, Krzysztof Kozlowski, Chanwoo Choi,
Kyungmin Park, MyungJoo Ham, Alexandre Bailon,
kernel@pengutronix.de, Fabio Estevam, Shawn Guo, Aisheng Dong,
devicetree@vger.kernel.org, dl-linux-imx
In-Reply-To: <CAL_JsqLj9FdoSwt7HZwoX42GS9RJ6Zeze=bUZs-tia2oS+OzUA@mail.gmail.com>
On 24.09.2019 00:04, Rob Herring wrote:
> On Mon, Sep 23, 2019 at 12:42 PM Leonard Crestez
> <leonard.crestez@nxp.com> wrote:
>>
>> On 17.09.2019 23:20, Rob Herring wrote:
>>> On Fri, Aug 23, 2019 at 05:36:56PM +0300, Leonard Crestez wrote:
>>>> The interconnect-node-id property is parsed by the imx interconnect
>>>> driver to find nodes on which frequencies can be adjusted.
>>>>
>>>> Add #interconnect-cells so that device drivers can request paths from
>>>> bus nodes instead of requiring a separate "virtual" node to represent
>>>> the interconnect itself.
>>>>
>>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>>> ---
>>>> Documentation/devicetree/bindings/devfreq/imx-ddrc.yaml | 5 +++++
>>>> Documentation/devicetree/bindings/devfreq/imx.yaml | 5 +++++
>>>> 2 files changed, 10 insertions(+)
>>>
>>> Please combine this with the other series for devfreq support.
>>
>> I understand that having two series which add to the same bindings file
>> is odd but the devfreq and interconnect parts are independent to a very
>> large degree and devfreq can be useful on it's own.
>
> To start with, I'm suspicious of any 'devfreq' binding because that's
> a Linux thing. I somewhat expect that the interconnect binding should
> replace the devfreq binding, but I haven't been able to investigate.
>
> Design something that matches the structure of the h/w not how Linux
> drivers happen to be structured. I can't tell what that is without any
> context around adding a couple of properties. Nor do I have the time
> to dig into each SoC vendor's bus structure if it's even documented
> publicly.
Device tree binding files are organized based on linux subsystems but
otherwise there's little particularly specific to "devfreq" in this new
binding.
An imx NIC or NOC is a physical component of a SOC which can run at a
variable clock speed. The device binding uses standard clk and opp
tables in meaningful ways so that first part is reasonable.
I also want to implement an interconnect provider but an "interconnect"
is not a single device but rather a graph of discrete buses. Some options:
* Add a custom virtual device, easy but not upstreamable.
* Have a single icc provider device use the individual buses as
"proxies" for OF parting. Implemented in this series but not very pretty.
* Pick the "main noc" as the single interconnect provider?
Alternatively the approach of defining the graph in the driver could be
dropped and everything could be described in DT (quite verbose). This
seems to be what Samsung is doing:
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=176291
It might even possible to use of_graph; this is complicated but the NICs
and NOCs do in fact have discrete ports with assignable properties.
> I also don't follow why you need 'interconnect-node-id' and if you do,
> it should be a common property.
The "interconnect-node-id" property in devicetree identifies nodes from
the interconnect graph; for example the DDRC node identifies itself as
IMX8MM_ICS_DRAM.
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [alsa-devel] Propagating audio properties along the audio path
From: Marc Gonzalez @ 2019-09-24 14:26 UTC (permalink / raw)
To: Charles Keepax
Cc: alsa-devel, Mark Brown, Takashi Iwai, Linux ARM, Liam Girdwood
In-Reply-To: <20190924135219.GQ10204@ediswmail.ad.cirrus.com>
On 24/09/2019 15:52, Charles Keepax wrote:
> In general the ALSA framework doesn't really allow for stream
> params to change whilst the stream is active. Doing so is
> also normally very hard for the types of hardware usually
> involved. For example changing the clocks on a running I2S bus,
> very difficult to get both ends to pick up those changes at
> exactly the correct sample. Some newer buses like soundwire
> have more support for things like this were the ends of the
> link can synchronise changes but even there that is normally
> used for adding/removing streams from the bus, not reconfiguring
> a running stream.
This jives with what "filt3r" wrote on #alsa-soc
"at one point we were just closing the stream (somehow) if we detected
a change in e.g. sample-rate, so the user-space application would fail
on snd_pcm_readi()"
snd_pcm_stop(p_spdif->capture_stream, SNDRV_PCM_STATE_DISCONNECTED);
> In your case above I would imagine the system would probably be
> setup where the DSP handles the conversion between the params
> requested from the receiver and those requested by user-space.
> One of the intentions of DPCM was to allow the backend
> (DSP-receiver here) to have different params to the frontend
> (DSP-userspace here). Although as you note you still probably
> need to add something to propagate those changes to the DSP. What
> form does the physical link between the receiver and the DSP
> take?
The setup looks like this:
A = Some kind of audio source, typically a TV or game console
B = The arm64 SoC, equipped with some nice speakers
HDMI
A ------> B
If we look inside B, we actually have
B1 = an eARC receiver (input = HDMI, output = I2S)
B2 = an audio DSP (input = I2S, output = speakers)
I2S ?
B1 -----> B2 -----> speakers
To answer your question, B1 and B2 are connected via I2S.
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 0/6] mm / virtio: Provide support for unused page reporting
From: Michal Hocko @ 2019-09-24 14:23 UTC (permalink / raw)
To: Alexander Duyck
Cc: yang.zhang.wz, pagupta, kvm, david, lcapitulino, linux-mm,
alexander.h.duyck, aarcange, virtio-dev, mst, willy, wei.w.wang,
vbabka, riel, dan.j.williams, linux-arm-kernel, osalvador, nitesh,
konrad.wilk, dave.hansen, linux-kernel, pbonzini, akpm, mgorman
In-Reply-To: <20190918175109.23474.67039.stgit@localhost.localdomain>
On Wed 18-09-19 10:52:25, Alexander Duyck wrote:
[...]
> In order to try and keep the time needed to find a non-reported page to
> a minimum we maintain a "reported_boundary" pointer. This pointer is used
> by the get_unreported_pages iterator to determine at what point it should
> resume searching for non-reported pages. In order to guarantee pages do
> not get past the scan I have modified add_to_free_list_tail so that it
> will not insert pages behind the reported_boundary.
>
> If another process needs to perform a massive manipulation of the free
> list, such as compaction, it can either reset a given individual boundary
> which will push the boundary back to the list_head, or it can clear the
> bit indicating the zone is actively processing which will result in the
> reporting process resetting all of the boundaries for a given zone.
Is this any different from the previous version? The last review
feedback (both from me and Mel) was that we are not happy to have an
externally imposed constrains on how the page allocator is supposed to
maintain its free lists.
If this is really the only way to go forward then I would like to hear
very convincing arguments about other approaches not being feasible.
There are none in this cover letter unfortunately. This will be really a
hard sell without them.
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
From: Paolo Bonzini @ 2019-09-24 14:20 UTC (permalink / raw)
To: Jianyong Wu (Arm Technology China), netdev@vger.kernel.org,
yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de,
sean.j.christopherson@intel.com, maz@kernel.org,
richardcochran@gmail.com, Mark Rutland, Will Deacon,
Suzuki Poulose
Cc: Justin He (Arm Technology China), kvm@vger.kernel.org,
Steve Capper, linux-kernel@vger.kernel.org,
Kaly Xin (Arm Technology China), nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <HE1PR0801MB1676A9D4A58118144F5C7B54F4850@HE1PR0801MB1676.eurprd08.prod.outlook.com>
On 23/09/19 06:57, Jianyong Wu (Arm Technology China) wrote:
>> On 19/09/19 11:46, Jianyong Wu (Arm Technology China) wrote:
>>>> On 18/09/19 11:57, Jianyong Wu (Arm Technology China) wrote:
>>>>> Paolo Bonzini wrote:
>>>>>> This is not Y2038-safe. Please use ktime_get_real_ts64 instead,
>>>>>> and split the 64-bit seconds value between val[0] and val[1].
>>>
>>> Val[] should be long not u32 I think, so in arm64 I can avoid that
>>> Y2038_safe, but also need rewrite for arm32.
>>
>> I don't think there's anything inherently wrong with u32 val[], and as you
>> notice it lets you reuse code between arm and arm64. It's up to you and
>> Marc to decide.
>>
> To compatible 32-bit, Integrates second value and nanosecond value as a nanosecond value then split it into val[0] and val[1] and split cycle value into val[2] and val[3],
> In this way, time will overflow at Y2262.
> WDYT?
So if I understand correctly you'd multiply by 10^9 (or better shift by
30) the nanoseconds.
That works, but why not provide 5 output registers? Alternatively, take
an address as input and write there.
Finally, on x86 we added an argument for the CLOCK_* that is being read
(currently only CLOCK_REALTIME, but having room for extensibility in the
API is always nice).
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] Add the Mobiveil EP and Layerscape Gen4 EP driver support
From: Russell King - ARM Linux admin @ 2019-09-24 14:18 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, devicetree, lorenzo.pieralisi, linux-pci,
Zhiqiang.Hou, linux-kernel, leoyang.li, Minghuan.Lian, robh+dt,
linux-arm-kernel, bhelgaas, andrew.murray, kishon, shawnguo,
mingkai.hu
In-Reply-To: <20190916021742.22844-1-xiaowei.bao@nxp.com>
On Mon, Sep 16, 2019 at 10:17:36AM +0800, Xiaowei Bao wrote:
> This patch set are for adding Mobiveil EP driver and adding PCIe Gen4
> EP driver of NXP Layerscape platform.
>
> This patch set depends on:
> https://patchwork.kernel.org/project/linux-pci/list/?series=159139
>
> Xiaowei Bao (6):
> PCI: mobiveil: Add the EP driver support
> dt-bindings: Add DT binding for PCIE GEN4 EP of the layerscape
> PCI: mobiveil: Add PCIe Gen4 EP driver for NXP Layerscape SoCs
> PCI: mobiveil: Add workaround for unsupported request error
> arm64: dts: lx2160a: Add PCIe EP node
> misc: pci_endpoint_test: Add the layerscape PCIe GEN4 EP device
> support
>
> .../bindings/pci/layerscape-pcie-gen4.txt | 28 +-
> MAINTAINERS | 3 +
> arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 56 ++
> drivers/misc/pci_endpoint_test.c | 2 +
> drivers/pci/controller/mobiveil/Kconfig | 22 +-
> drivers/pci/controller/mobiveil/Makefile | 2 +
> .../controller/mobiveil/pcie-layerscape-gen4-ep.c | 169 ++++++
> drivers/pci/controller/mobiveil/pcie-mobiveil-ep.c | 568 +++++++++++++++++++++
> drivers/pci/controller/mobiveil/pcie-mobiveil.c | 99 +++-
> drivers/pci/controller/mobiveil/pcie-mobiveil.h | 72 +++
> 10 files changed, 1009 insertions(+), 12 deletions(-)
> create mode 100644 drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c
> create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil-ep.c
Hi,
I've applied "PCI: mobiveil: Fix the CPU base address setup in inbound
window" and your patch set to 5.3, which seems to be able to detect the
PCIe card I have plugged in:
layerscape-pcie-gen4 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
layerscape-pcie-gen4 3800000.pcie: MEM 0xa040000000..0xa07fffffff -> 0x40000000
layerscape-pcie-gen4 3800000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [mem 0xa040000000-0xa07fffffff] (bus address
[0x40000000-0x7fffffff])
pci 0000:00:00.0: [1957:8d90] type 01 class 0x060400
pci 0000:00:00.0: enabling Extended Tags
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:01:00.0: [15b3:6750] type 00 class 0x020000
pci 0000:01:00.0: reg 0x10: [mem 0xa040000000-0xa0400fffff 64bit]
pci 0000:01:00.0: reg 0x18: [mem 0xa040800000-0xa040ffffff 64bit pref]
pci 0000:01:00.0: reg 0x30: [mem 0xa041000000-0xa0410fffff pref]
pci 0000:00:00.0: up support 3 enabled 0
pci 0000:00:00.0: dn support 1 enabled 0
pci 0000:00:00.0: BAR 9: assigned [mem 0xa040000000-0xa0407fffff 64bit pref]
pci 0000:00:00.0: BAR 8: assigned [mem 0xa040800000-0xa0409fffff]
pci 0000:01:00.0: BAR 2: assigned [mem 0xa040000000-0xa0407fffff 64bit pref]
pci 0000:01:00.0: BAR 0: assigned [mem 0xa040800000-0xa0408fffff 64bit]
pci 0000:01:00.0: BAR 6: assigned [mem 0xa040900000-0xa0409fffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [mem 0xa040800000-0xa0409fffff]
pci 0000:00:00.0: bridge window [mem 0xa040000000-0xa0407fffff 64bit pref]
pci 0000:00:00.0: Max Payload Size set to 256/ 256 (was 128), Max Read Rq 256pci 0000:01:00.0: Max Payload Size set to 256/ 256 (was 128), Max Read Rq 256pcieport 0000:00:00.0: PCIe capabilities: 0x13
pcieport 0000:00:00.0: init_service_irqs: -19
However, a bit later in the kernel boot, I get:
SError Interrupt on CPU1, code 0xbf000002 -- SError
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0+ #392
Hardware name: SolidRun LX2160A COM express type 7 module (DT)
pstate: 60400085 (nZCv daIf +PAN -UAO)
pc : pci_generic_config_read+0xb0/0xc0
lr : pci_generic_config_read+0x1c/0xc0
sp : ffffff8010f9baf0
x29: ffffff8010f9baf0 x28: ffffff8010d620a0
x27: ffffff8010d79000 x26: ffffff8010d62000
x25: ffffff8010cb06d4 x24: 0000000000000000
x23: ffffff8010e499b8 x22: ffffff8010f9bbaf
x21: 0000000000000000 x20: ffffffe2eda11800
x19: ffffff8010f62158 x18: ffffff8010bdede0
x17: ffffff8010bdede8 x16: ffffff8010b96970
x15: ffffffffffffffff x14: ffffffffff000000
x13: ffffffffffffffff x12: 0000000000000030
x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
x9 : 2dff716475687163 x8 : ffffffffffffffff
x7 : fefefefefefefefe x6 : 0000000000000000
x5 : 0000000000000000 x4 : ffffff8010f9bb6c
x3 : 0000000000000001 x2 : 0000000000000003
x1 : 0000000000000000 x0 : 0000000000000000
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0+ #392
Hardware name: SolidRun LX2160A COM express type 7 module (DT)
Call trace:
dump_backtrace+0x0/0x120
show_stack+0x14/0x1c
dump_stack+0x9c/0xc0
panic+0x148/0x34c
print_tainted+0x0/0xa8
arm64_serror_panic+0x74/0x80
do_serror+0x8c/0x13c
el1_error+0xbc/0x160
pci_generic_config_read+0xb0/0xc0
pci_bus_read_config_byte+0x64/0x90
pci_read_config_byte+0x40/0x48
pci_assign_irq+0x34/0xc8
pci_device_probe+0x28/0x148
really_probe+0x1c4/0x2d0
driver_probe_device+0x58/0xfc
device_driver_attach+0x68/0x70
__driver_attach+0x94/0xdc
bus_for_each_dev+0x50/0xa0
driver_attach+0x20/0x28
bus_add_driver+0x14c/0x200
driver_register+0x6c/0x124
__pci_register_driver+0x48/0x50
mlx4_init+0x154/0x180
do_one_initcall+0x30/0x250
kernel_init_freeable+0x23c/0x32c
kernel_init+0x10/0xfc
ret_from_fork+0x10/0x18
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0002,21006008
Memory Limit: none
and there it dies. Any ideas?
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 00/14] dmaengine/soc: Add Texas Instruments UDMA support
From: Peter Ujfalusi @ 2019-09-24 13:54 UTC (permalink / raw)
To: vkoul, robh+dt, nm, ssantosh
Cc: devicetree, grygorii.strashko, lokeshvutla, j-keerthy,
linux-kernel, t-kristo, tony, dmaengine, dan.j.williams,
linux-arm-kernel
In-Reply-To: <20190730093450.12664-1-peter.ujfalusi@ti.com>
Hi,
On 30/07/2019 12.34, Peter Ujfalusi wrote:
> Changes since v1
> (https://patchwork.kernel.org/project/linux-dmaengine/list/?series=114105&state=*)
> - Added support for j721e
> - Based on 5.3-rc2
> - dropped ti_sci API patch for RM management as it is already upstream
> - dropped dmadev_get_slave_channel() patch, using __dma_request_channel()
> - Added Rob's Reviewed-by to ringacc DT binding document patch
> - DT bindings changes:
> - linux,udma-mode is gone, I have a simple lookup table in the driver to flag
> TR channels.
> - Support for j721e
> - Fix bug in of_node_put() handling in xlate function
I have addressed locally all the comments given for v2 so far. Is there
anything else I need to change for v3?
Regards,
- Péter
>
> Changes since RFC (https://patchwork.kernel.org/cover/10612465/):
> - Based on linux-next (20190506) which now have the ti_sci interrupt support
> - The series can be applied and the UDMA via DMAengine API will be functional
> - Included in the series: ti_sci Resource management API, cppi5 header and
> driver for the ring accelerator.
> - The DMAengine core patches have been updated as per the review comments for
> earlier submittion.
> - The DMAengine driver patch is artificially split up to 6 smaller patches
>
> The k3-udma driver implements the Data Movement Architecture described in
> AM65x TRM (http://www.ti.com/lit/pdf/spruid7) and
> j721e TRM (http://www.ti.com/lit/pdf/spruil1)
>
> This DMA architecture is a big departure from 'traditional' architecture where
> we had either EDMA or sDMA as system DMA.
>
> Packet DMAs were used as dedicated DMAs to service only networking (Kesytone2)
> or USB (am335x) while other peripherals were serviced by EDMA.
>
> In AM65x/j721e the UDMA (Unified DMA) is used for all data movment within the
> SoC, tasked to service all peripherals (UART, McSPI, McASP, networking, etc).
>
> The NAVSS/UDMA is built around CPPI5 (Communications Port Programming Interface)
> and it supports Packet mode (similar to CPPI4.1 in Keystone2 for networking) and
> TR mode (similar to EDMA descriptor).
> The data movement is done within a PSI-L fabric, peripherals (including the
> UDMA-P) are not addressed by their I/O register as with traditional DMAs but
> with their PSI-L thread ID.
>
> In AM65x/j721e we have two main type of peripherals:
> Legacy: McASP, McSPI, UART, etc.
> to provide connectivity they are serviced by PDMA (Peripheral DMA)
> PDMA threads are locked to service a given peripheral, for example PSI-L thread
> 0x4400/0xc400 is to service McASP0 rx/tx.
> The PDMa configuration can be done via the UDMA Real Time Peer registers.
> Native: Networking, security accelerator
> these peripherals have native support for PSI-L.
>
> To be able to use the DMA the following generic steps need to be taken:
> - configure a DMA channel (tchan for TX, rchan for RX)
> - channel mode: Packet or TR mode
> - for memcpy a tchan and rchan pair is used.
> - for packet mode RX we also need to configure a receive flow to configure the
> packet receiption
> - the source and destination threads must be paired
> - at minimum one pair of rings need to be configured:
> - tx: transfer ring and transfer completion ring
> - rx: free descriptor ring and receive ring
> - two interrupts: UDMA-P channel interrupt and ring interrupt for tc_ring/r_ring
> - If the channel is in packet mode or configured to memcpy then we only need
> one interrupt from the ring, events from UDMAP is not used.
>
> When the channel setup is completed we only interract with the rings:
> - TX: push a descriptor to t_ring and wait for it to be pushed to the tc_ring by
> the UDMA-P
> - RX: push a descriptor to the fd_ring and waith for UDMA-P to push it back to
> the r_ring.
>
> Since we have FIFOs in the DMA fabric (UDMA-P, PSI-L and PDMA) which was not the
> case in previous DMAs we need to report the amount of data held in these FIFOs
> to clients (delay calculation for ALSA, UART FIFO flush support).
>
> Metadata support:
> DMAengine user driver was posted upstream based/tested on the v1 of the UDMA
> series: https://lkml.org/lkml/2019/6/28/20
> SA2UL is using the metadata DMAengine API.
>
> Note on the last patch:
> In Keystone2 the networking had dedicated DMA (packet DMA) which is not the case
> anymore and the DMAengine API currently missing support for the features we
> would need to support networking, things like
> - support for receive descriptor 'classification'
> - we need to support several receive queues for a channel.
> - the queues are used for packet priority handling for example, but they can be
> used to have pools of descriptors for different sizes.
> - out of order completion of descriptors on a channel
> - when we have several queues to handle different priority packets the
> descriptors will be completed 'out-of-order'
> - NAPI type of operation (polling instead of interrupt driven transfer)
> - without this we can not sustain gigabit speeds and we need to support NAPI
> - not to limit this to networking, but other high performance operations
>
> It is my intention to work on these to be able to remove the 'glue' layer and
> switch to DMAengine API - or have an API aside of DMAengine to have generic way
> to support networking, but given how controversial and not trivial these changes
> are we need something to support networking.
>
> The series (+DT patch to enabled UDMA/PDMA on AM65x) on top of 5.3-rc2 is
> available:
> https://github.com/omap-audio/linux-audio.git peter/udma/series_v2-5.3-rc2
>
> Regards,
> Peter
> ---
> Grygorii Strashko (3):
> bindings: soc: ti: add documentation for k3 ringacc
> soc: ti: k3: add navss ringacc driver
> dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
>
> Peter Ujfalusi (11):
> dmaengine: doc: Add sections for per descriptor metadata support
> dmaengine: Add metadata_ops for dma_async_tx_descriptor
> dmaengine: Add support for reporting DMA cached data amount
> dmaengine: ti: Add cppi5 header for UDMA
> dt-bindings: dma: ti: Add document for K3 UDMA
> dmaengine: ti: New driver for K3 UDMA - split#1: defines, structs, io
> func
> dmaengine: ti: New driver for K3 UDMA - split#2: probe/remove, xlate
> and filter_fn
> dmaengine: ti: New driver for K3 UDMA - split#3: alloc/free
> chan_resources
> dmaengine: ti: New driver for K3 UDMA - split#4: dma_device callbacks
> 1
> dmaengine: ti: New driver for K3 UDMA - split#5: dma_device callbacks
> 2
> dmaengine: ti: New driver for K3 UDMA - split#6: Kconfig and Makefile
>
> .../devicetree/bindings/dma/ti/k3-udma.txt | 170 +
> .../devicetree/bindings/soc/ti/k3-ringacc.txt | 59 +
> Documentation/driver-api/dmaengine/client.rst | 75 +
> .../driver-api/dmaengine/provider.rst | 46 +
> drivers/dma/dmaengine.c | 73 +
> drivers/dma/dmaengine.h | 8 +
> drivers/dma/ti/Kconfig | 22 +
> drivers/dma/ti/Makefile | 2 +
> drivers/dma/ti/k3-udma-glue.c | 1039 +++++
> drivers/dma/ti/k3-udma-private.c | 124 +
> drivers/dma/ti/k3-udma.c | 3479 +++++++++++++++++
> drivers/dma/ti/k3-udma.h | 160 +
> drivers/soc/ti/Kconfig | 17 +
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/k3-ringacc.c | 1191 ++++++
> include/dt-bindings/dma/k3-udma.h | 10 +
> include/linux/dma/k3-udma-glue.h | 125 +
> include/linux/dma/ti-cppi5.h | 996 +++++
> include/linux/dmaengine.h | 110 +
> include/linux/soc/ti/k3-ringacc.h | 262 ++
> 20 files changed, 7969 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-udma.txt
> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt
> create mode 100644 drivers/dma/ti/k3-udma-glue.c
> create mode 100644 drivers/dma/ti/k3-udma-private.c
> create mode 100644 drivers/dma/ti/k3-udma.c
> create mode 100644 drivers/dma/ti/k3-udma.h
> create mode 100644 drivers/soc/ti/k3-ringacc.c
> create mode 100644 include/dt-bindings/dma/k3-udma.h
> create mode 100644 include/linux/dma/k3-udma-glue.h
> create mode 100644 include/linux/dma/ti-cppi5.h
> create mode 100644 include/linux/soc/ti/k3-ringacc.h
>
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [alsa-devel] Propagating audio properties along the audio path
From: Charles Keepax @ 2019-09-24 13:52 UTC (permalink / raw)
To: Marc Gonzalez; +Cc: alsa-devel, Takashi Iwai, Linux ARM
In-Reply-To: <878168cb-07e0-cdfd-37e9-9b9fb229155b@free.fr>
On Mon, Sep 23, 2019 at 12:47:33PM +0200, Marc Gonzalez wrote:
> On 20/09/2019 11:50, Marc Gonzalez wrote:
>
> > One more concern popped up: if the audio stream changes mid-capture
> > (for example, a different TV program uses different audio settings),
> > then I would detect this in the eARC receiver, but it's not clear
> > (to me) how to propagate the info to the DSP...
> >
> > I'm not even sure when the HW params actually get applied...
> > Is it for SNDRV_PCM_IOCTL_PREPARE? SNDRV_PCM_IOCTL_START?
>
> I enabled debug logs in the sound layer:
> echo "file sound/* +fpm" > /sys/kernel/debug/dynamic_debug/control
>
> and sprinkled dump_stack() in several driver callbacks.
>
> When I run 'tinycap /tmp/earc.wav -t 10 -r 44100 -b 32'
> I see the open/SyS_openat call and the capture ioctl call
> which together generate calls to
> 1) dpcm_fe_dai_open
> 2) dpcm_fe_dai_hw_params
> 3) dpcm_fe_dai_prepare
> 4) dpcm_fe_dai_trigger
>
> But everything looks "synchronous", as in "reaction to user-space commands".
> I don't see how "asynchronous" events are dealt with, such as the stream
> params changing while a capture is active?
>
In general the ALSA framework doesn't really allow for stream
params to change whilst the stream is active. Doing so is
also normally very hard for the types of hardware usually
involved. For example changing the clocks on a running I2S bus,
very difficult to get both ends to pick up those changes at
exactly the correct sample. Some newer buses like soundwire
have more support for things like this were the ends of the
link can synchronise changes but even there that is normally
used for adding/removing streams from the bus, not reconfiguring
a running stream.
In your case above I would imagine the system would probably be
setup where the DSP handles the conversion between the params
requested from the receiver and those requested by user-space.
One of the intentions of DPCM was to allow the backend
(DSP-receiver here) to have different params to the frontend
(DSP-userspace here). Although as you note you still probably
need to add something to propogate those changes to the DSP. What
form does the physical link between the receiver and the DSP
take?
Thanks,
Charles
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 11/15] dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm
From: Schrempf Frieder @ 2019-09-24 13:27 UTC (permalink / raw)
To: yibin.gong@nxp.com
Cc: Fabio Estevam, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, vkoul@kernel.org, NXP Linux Team,
Pengutronix Kernel Team, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190610081753.11422-12-yibin.gong@nxp.com>
Hi Robin,
> From: Robin Gong <yibin.gong at nxp.com>
>
> Because the number of ecspi1 rx event on i.mx8mm is 0, the condition
> check ignore such special case without dma channel enabled, which caused
> ecspi1 rx works failed. Actually, no need to check event_id0/event_id1
> and replace checking 'event_id1' with 'DMA_DEV_TO_DEV', so that configure
> event_id1 only in case DEV_TO_DEV.
>
> Signed-off-by: Robin Gong <yibin.gong at nxp.com>
> Acked-by: Vinod Koul <vkoul at kernel.org>
I have a custom board with i.MX8MM and SPI flash on ecspi1. I'm
currently testing with v5.3 and as SPI didn't work, I tried two
different things:
1. Removing 'dmas' and 'dma-names' from the ecspi1 node in imx8mm.dtsi,
to use PIO instead of DMA. This works as expected and the driver
boots with the following messages:
spi_imx 30820000.spi: dma setup error -19, use pio
m25p80 spi0.0: mx25v8035f (1024 Kbytes)
spi_imx 30820000.spi: probed
2. Applying your patchset and use DMA. In this case, the flash also
works fine, but there are some error messages printed while booting:
spi_master spi0: I/O Error in DMA RX
m25p80 spi0.0: SPI transfer failed: -110
spi_master spi0: failed to transfer one message from queue
m25p80 spi0.0: mx25v8035f (1024 Kbytes)
spi_imx 30820000.spi: probed
It would be great to get your patches merged and fix SPI + DMA, but for
i.MX8MM, we need to get rid of the error messages. Do you have an idea,
what's wrong?
Thanks,
Frieder
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm: sun8i-ui/vi: Fix layer zpos change/atomic modesetting
From: Ondřej Jirman @ 2019-09-24 12:40 UTC (permalink / raw)
To: Maxime Ripard
Cc: David Airlie, linux-kernel, dri-devel, Chen-Yu Tsai,
Daniel Vetter, linux-arm-kernel
In-Reply-To: <20190920151142.ijistzhtcaenehx6@gilmour>
On Fri, Sep 20, 2019 at 05:11:42PM +0200, Maxime Ripard wrote:
> On Thu, Sep 19, 2019 at 03:12:44PM +0200, Ondřej Jirman wrote:
> > On Thu, Sep 19, 2019 at 02:20:58PM +0200, megous hlavni wrote:
> > > On Wed, Sep 18, 2019 at 10:16:17PM +0200, Maxime Ripard wrote:
> > > > On Wed, Sep 18, 2019 at 05:23:09PM +0200, Ondřej Jirman wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, Sep 18, 2019 at 04:17:34PM +0200, Maxime Ripard wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Sun, Sep 15, 2019 at 12:03:37AM +0200, megous@megous.com wrote:
> > > > > > > From: Ondrej Jirman <megous@megous.com>
> > > > > > >
> > > > > > > There are various issues that this re-work of sun8i_[uv]i_layer_enable
> > > > > > > function fixes:
> > > > > > >
> > > > > > > - Make sure that we re-initialize zpos on reset
> > > > > > > - Minimize register updates by doing them only when state changes
> > > > > > > - Fix issue where DE pipe might get disabled even if it is no longer
> > > > > > > used by the layer that's currently calling sun8i_ui_layer_enable
> > > > > > > - .atomic_disable callback is not really needed because .atomic_update
> > > > > > > can do the disable too, so drop the duplicate code
> > > > > > >
> > > > > > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > > > >
> > > > > > It looks like these fixes should be in separate patches. Is there any
> > > > > > reason it's not the case?
> > > > >
> > > > > Bullet points just describe the resulting effect/benefits of the change to fix
> > > > > the pipe control register update issue (see the referenced e-mail).
> > > >
> > > > It's definitely ok to have multiple patches needed to address a single
> > > > perceived issue.
> > >
> > > Yes, but I can't simply split the patch. In order for each change to work on its
> > > own, they'd have to be done differently than the final result.
> > >
> > > I wouldn't mind at all if it was just a simple splitting, but you're asking
> > > for too much work, this time, for no benefit that I can see.
> > >
> > > > A commit is not about what you're fixing but what you're changing. And
> > > > the fact that you have tha bullet list in the first place proves that
> > > > you have multiple logical changes in your patch.
> > > >
> > > > And even then, your commit log mentions that you're fixing multiple
> > > > issues (without explaining them).
> > >
> > > I can reword the commit message if that helps, and skip the bullet list if it
> > > is confusing. There's a single core issue and that is that the driver doesn't
> > > update the pipe/channel configuration correctly leading to disabling of
> > > arbitrary layers (not even those being updated - update of UI layer may disable
> > > VI layer as a side effect for example) at wrong times. And only changes
> > > necessary to debug/fix this are included.
> >
> > How about this:
> >
> > A problem was found where identical configuration of planes leads
> > to different register settings at the HW layer when using a X server
> > with modesetting driver and one plane marked as a cursor.
>
> We don't have a cursor plane.
Did I say we did? I only wrote that the problem was found this way. It's there
regardless of how it was revealed.
> > On first run of the X server, only the black screen and the layer
> > containing the cursor is visible. Switching to console and back
> > corrects the situation.
> >
> > I have dumped registers, and found out this:
> >
> > (In both cases there are two enabled planes, plane 1 with zpos 0 and
> > plane 3 with zpos 1).
> >
> > 1) First Xorg run:
> >
> > 0x01101000 : 00000201
> > 0x01101080 : 00000030
> >
> > BLD_FILL_COLOR_CTL: (aka SUN8I_MIXER_BLEND_PIPE_CTL)
> > P1_EN
> >
> > BLD_CH_RTCTL: (aka SUN8I_MIXER_BLEND_ROUTE)
> > P0_RTCTL channel0
> > P1_RTCTL channel3
> >
> > 2) After switch to console and back to Xorg:
> >
> > 0x01101000 : 00000301
> > 0x01101080 : 00000031
> >
> > BLD_FILL_COLOR_CTL:
> > P1_EN and P0_EN
> >
> > BLD_CH_RTCTL:
> > P0_RTCTL channel1
> > P1_RTCTL channel3
> >
> > What happens is that sun8i_ui_layer_enable() function may disable
> > blending pipes even if it is no longer assigned to its layer, because
> > of incorrect state/zpos tracking in the driver.
> >
> > In particular, layer 1 is configured to zpos 0 and thus uses pipe 0.
> > When layer 3 is enabled by X server, sun8i_ui_layer_enable() will get
> > called with old_zpos=0 zpos=1, which will lead to disabling of pipe 0.
> >
> > In general this issue can happen to any layer during enable or zpos
> > changes on multiple layers at once.
> >
> > To correct this we now pass previous enabled/disabled state of the
> > layer, and pass real previous zpos of the layer to
> > sun8i_ui_layer_enable() and rework the sun8i_ui_layer_enable() function
> > to react to the state changes correctly. In order to not complicate
> > the atomic_disable callback with all of the above changes, we simply
> > remove it and implement all the chanes as part of atomic_update, which
> > also reduces the code duplication.
>
> I'm not even sure why we need that old state. Can't we just reset
> completely the whole thing and do the configuration all over again?
That would be nice from a dev standpoint if we can get a complete state for all
planes at once from DRM core, but how? DRM helper gives callbacks
for updating individual planes with prev and new state. These individual layer
change notifications don't map nicely to how pipes are represented in the mixer
registers.
> That description just looks to me like the reset is not done properly,
> and now we have to deal with the fallouts later on.
What in particular?
> > To make this all work, initial zpos positions of all layers need to be
> > restored to initial values on reset.
>
> And this also fixes a whole other bunch of issues, and can be made
> very trivially in a separate patch.
Maybe reset should also reset registers?
regards,
o.
> Maxime
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 0/2] mm/debug: Add tests for architecture exported page table helpers
From: Mike Rapoport @ 2019-09-24 12:31 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, Gerald Schaefer, linux-snps-arc,
linux-arm-kernel, Kees Cook, Anshuman Khandual, Masahiro Yamada,
Mark Brown, Dan Williams, Vlastimil Babka, Christophe Leroy,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
Dave Hansen, linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller, Mike Kravetz
In-Reply-To: <20190924115101.p6y7vpbtgmj5qjku@box>
On Tue, Sep 24, 2019 at 02:51:01PM +0300, Kirill A. Shutemov wrote:
> On Fri, Sep 20, 2019 at 12:03:21PM +0530, Anshuman Khandual wrote:
> > This series adds a test validation for architecture exported page table
> > helpers. Patch in the series adds basic transformation tests at various
> > levels of the page table. Before that it exports gigantic page allocation
> > function from HugeTLB.
> >
> > This test was originally suggested by Catalin during arm64 THP migration
> > RFC discussion earlier. Going forward it can include more specific tests
> > with respect to various generic MM functions like THP, HugeTLB etc and
> > platform specific tests.
> >
> > https://lore.kernel.org/linux-mm/20190628102003.GA56463@arrakis.emea.arm.com/
> >
> > Testing:
> >
> > Successfully build and boot tested on both arm64 and x86 platforms without
> > any test failing. Only build tested on some other platforms. Build failed
> > on some platforms (known) in pud_clear_tests() as there were no available
> > __pgd() definitions.
> >
> > - ARM32
> > - IA64
>
> Hm. Grep shows __pgd() definitions for both of them. Is it for specific
> config?
For ARM32 it's defined only for 3-lelel page tables, i.e with LPAE on.
For IA64 it's defined for !STRICT_MM_TYPECHECKS which is even not a config
option, but a define in arch/ia64/include/asm/page.h
> --
> Kirill A. Shutemov
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: at91: avoid sleeping early
From: Uwe Kleine-König @ 2019-09-24 12:21 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Stephen Boyd, linux-kernel, Michael Turquette, Claudiu Beznea,
linux-clk, linux-arm-kernel
In-Reply-To: <20190920153906.20887-1-alexandre.belloni@bootlin.com>
On Fri, Sep 20, 2019 at 05:39:06PM +0200, Alexandre Belloni wrote:
> It is not allowed to sleep to early in the boot process and this may lead
> to kernel issues if the bootloader didn't prepare the slow clock and main
> clock.
>
> This results in the following error and dump stack on the AriettaG25:
> bad: scheduling from the idle thread!
>
> Ensure it is possible to sleep, else simply have a delay.
>
> Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
See below for a comment.
> Note that this was already discussed a while ago and Arnd said this approach was
> reasonable:
> https://lore.kernel.org/lkml/6120818.MyeJZ74hYa@wuerfel/
>
> drivers/clk/at91/clk-main.c | 5 ++++-
> drivers/clk/at91/sckc.c | 20 ++++++++++++++++----
> 2 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
> index f607ee702c83..ccd48e7a3d74 100644
> --- a/drivers/clk/at91/clk-main.c
> +++ b/drivers/clk/at91/clk-main.c
> @@ -293,7 +293,10 @@ static int clk_main_probe_frequency(struct regmap *regmap)
> regmap_read(regmap, AT91_CKGR_MCFR, &mcfr);
> if (mcfr & AT91_PMC_MAINRDY)
> return 0;
> - usleep_range(MAINF_LOOP_MIN_WAIT, MAINF_LOOP_MAX_WAIT);
> + if (system_state < SYSTEM_RUNNING)
> + udelay(MAINF_LOOP_MIN_WAIT);
> + else
> + usleep_range(MAINF_LOOP_MIN_WAIT, MAINF_LOOP_MAX_WAIT);
Given that this construct is introduced several times, I wonder if we
want something like:
static inline void early_usleep_range(unsigned long min, unsigned long max)
{
if (system_state < SYSTEM_RUNNING)
udelay(min);
else
usleep_range(min, max);
}
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: at91: sam9x60: fix programmable clock
From: Alexandre Belloni @ 2019-09-24 12:00 UTC (permalink / raw)
To: Eugen.Hristev
Cc: sboyd, mturquette, linux-kernel, linux-clk, linux-arm-kernel
In-Reply-To: <1569321191-27606-1-git-send-email-eugen.hristev@microchip.com>
On 24/09/2019 10:39:09+0000, Eugen.Hristev@microchip.com wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> The prescaler mask for sam9x60 must be 0xff (8 bits).
> Being set to 0, means that we cannot set any prescaler, thus the
> programmable clocks do not work (except the case with prescaler 0)
> Set the mask accordingly in layout struct.
>
> Fixes: 01e2113de9a5 ("clk: at91: add sam9x60 pmc driver")
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/clk/at91/sam9x60.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/at91/sam9x60.c b/drivers/clk/at91/sam9x60.c
> index 9790ddf..86238d5 100644
> --- a/drivers/clk/at91/sam9x60.c
> +++ b/drivers/clk/at91/sam9x60.c
> @@ -43,6 +43,7 @@ static const struct clk_pll_characteristics upll_characteristics = {
> };
>
> static const struct clk_programmable_layout sam9x60_programmable_layout = {
> + .pres_mask = 0xff,
> .pres_shift = 8,
> .css_mask = 0x1f,
> .have_slck_mck = 0,
> --
> 2.7.4
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Kirill A. Shutemov @ 2019-09-24 11:59 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, linux-mm@kvack.org, Punit Agrawal, Will Deacon,
Alex Van Brunt, Justin He (Arm Technology China), Marc Zyngier,
Anshuman Khandual, Matthew Wilcox,
Kaly Xin (Arm Technology China), hejianet@gmail.com,
Ralph Campbell, Suzuki Poulose, Jérôme Glisse,
Thomas Gleixner, nd, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, James Morse, Andrew Morton,
Robin Murphy, Kirill A. Shutemov
In-Reply-To: <20190924103324.GB41214@arrakis.emea.arm.com>
On Tue, Sep 24, 2019 at 11:33:25AM +0100, Catalin Marinas wrote:
> On Tue, Sep 24, 2019 at 06:43:06AM +0000, Justin He (Arm Technology China) wrote:
> > Catalin Marinas wrote:
> > > On Sat, Sep 21, 2019 at 09:50:54PM +0800, Jia He wrote:
> > > > @@ -2151,21 +2163,53 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
> > > > * fails, we just zero-fill it. Live with it.
> > > > */
> > > > if (unlikely(!src)) {
> > > > - void *kaddr = kmap_atomic(dst);
> > > > - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> > > > + void *kaddr;
> > > > + pte_t entry;
> > > > + void __user *uaddr = (void __user *)(addr & PAGE_MASK);
> > > >
> > > > + /* On architectures with software "accessed" bits, we would
> > > > + * take a double page fault, so mark it accessed here.
> > > > + */
> [...]
> > > > + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
> > > > + vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr,
> > > > + &vmf->ptl);
> > > > + if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> > > > + entry = pte_mkyoung(vmf->orig_pte);
> > > > + if (ptep_set_access_flags(vma, addr,
> > > > + vmf->pte, entry, 0))
> > > > + update_mmu_cache(vma, addr, vmf->pte);
> > > > + } else {
> > > > + /* Other thread has already handled the fault
> > > > + * and we don't need to do anything. If it's
> > > > + * not the case, the fault will be triggered
> > > > + * again on the same address.
> > > > + */
> > > > + pte_unmap_unlock(vmf->pte, vmf->ptl);
> > > > + return false;
> > > > + }
> > > > + pte_unmap_unlock(vmf->pte, vmf->ptl);
> > > > + }
> [...]
> > > > +
> > > > + kaddr = kmap_atomic(dst);
> > >
> > > Since you moved the kmap_atomic() here, could the above
> > > arch_faults_on_old_pte() run in a preemptible context? I suggested to
> > > add a WARN_ON in patch 2 to be sure.
> >
> > Should I move kmap_atomic back to the original line? Thus, we can make sure
> > that arch_faults_on_old_pte() is in the context of preempt_disabled?
> > Otherwise, arch_faults_on_old_pte() may cause plenty of warning if I add
> > a WARN_ON in arch_faults_on_old_pte. I tested it when I enable the PREEMPT=y
> > on a ThunderX2 qemu guest.
>
> So we have two options here:
>
> 1. Change arch_faults_on_old_pte() scope to the whole system rather than
> just the current CPU. You'd have to wire up a new arm64 capability
> for the access flag but this way we don't care whether it's
> preemptible or not.
>
> 2. Keep the arch_faults_on_old_pte() per-CPU but make sure we are not
> preempted here. The kmap_atomic() move would do but you'd have to
> kunmap_atomic() before the return.
>
> I think the answer to my question below also has some implication on
> which option to pick:
>
> > > > /*
> > > > * This really shouldn't fail, because the page is there
> > > > * in the page tables. But it might just be unreadable,
> > > > * in which case we just give up and fill the result with
> > > > * zeroes.
> > > > */
> > > > - if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> > > > + if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
> > > > + /* Give a warn in case there can be some obscure
> > > > + * use-case
> > > > + */
> > > > + WARN_ON_ONCE(1);
> > >
> > > That's more of a question for the mm guys: at this point we do the
> > > copying with the ptl released; is there anything else that could have
> > > made the pte old in the meantime? I think unuse_pte() is only called on
> > > anonymous vmas, so it shouldn't be the case here.
>
> If we need to hold the ptl here, you could as well have an enclosing
> kmap/kunmap_atomic (option 2) with some goto instead of "return false".
Yeah, look like we need to hold ptl for longer. There is nothing I see
that would prevent clearing young bit under us otherwise.
--
Kirill A. Shutemov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: at91: sam9x60: fix programmable clock
From: Nicolas.Ferre @ 2019-09-24 11:53 UTC (permalink / raw)
To: Eugen.Hristev, mturquette, sboyd, alexandre.belloni, linux-clk,
linux-arm-kernel, linux-kernel
In-Reply-To: <1569321191-27606-1-git-send-email-eugen.hristev@microchip.com>
On 24/09/2019 at 12:39, Eugen Hristev - M18282 wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> The prescaler mask for sam9x60 must be 0xff (8 bits).
> Being set to 0, means that we cannot set any prescaler, thus the
> programmable clocks do not work (except the case with prescaler 0)
> Set the mask accordingly in layout struct.
>
> Fixes: 01e2113de9a5 ("clk: at91: add sam9x60 pmc driver")
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks Eugen. Best regards,
Nicolas
> ---
> drivers/clk/at91/sam9x60.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/at91/sam9x60.c b/drivers/clk/at91/sam9x60.c
> index 9790ddf..86238d5 100644
> --- a/drivers/clk/at91/sam9x60.c
> +++ b/drivers/clk/at91/sam9x60.c
> @@ -43,6 +43,7 @@ static const struct clk_pll_characteristics upll_characteristics = {
> };
>
> static const struct clk_programmable_layout sam9x60_programmable_layout = {
> + .pres_mask = 0xff,
> .pres_shift = 8,
> .css_mask = 0x1f,
> .have_slck_mck = 0,
>
--
Nicolas Ferre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 0/2] mm/debug: Add tests for architecture exported page table helpers
From: Kirill A. Shutemov @ 2019-09-24 11:51 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, Gerald Schaefer, linux-snps-arc,
linux-arm-kernel, Kees Cook, Masahiro Yamada, Mark Brown,
Dan Williams, Vlastimil Babka, Christophe Leroy,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller, Mike Kravetz
In-Reply-To: <1568961203-18660-1-git-send-email-anshuman.khandual@arm.com>
On Fri, Sep 20, 2019 at 12:03:21PM +0530, Anshuman Khandual wrote:
> This series adds a test validation for architecture exported page table
> helpers. Patch in the series adds basic transformation tests at various
> levels of the page table. Before that it exports gigantic page allocation
> function from HugeTLB.
>
> This test was originally suggested by Catalin during arm64 THP migration
> RFC discussion earlier. Going forward it can include more specific tests
> with respect to various generic MM functions like THP, HugeTLB etc and
> platform specific tests.
>
> https://lore.kernel.org/linux-mm/20190628102003.GA56463@arrakis.emea.arm.com/
>
> Testing:
>
> Successfully build and boot tested on both arm64 and x86 platforms without
> any test failing. Only build tested on some other platforms. Build failed
> on some platforms (known) in pud_clear_tests() as there were no available
> __pgd() definitions.
>
> - ARM32
> - IA64
Hm. Grep shows __pgd() definitions for both of them. Is it for specific
config?
--
Kirill A. Shutemov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] arm64: use generic free_initrd_mem()
From: Mike Rapoport @ 2019-09-24 11:18 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland
Cc: Mike Rapoport, Laura Abbott, linux-kernel, linux-arm-kernel,
Anshuman Khandual
From: Mike Rapoport <rppt@linux.ibm.com>
arm64 calls memblock_free() for the initrd area in its implementation of
free_initrd_mem(), but this call has no actual effect that late in the boot
process. By the time initrd is freed, all the reserved memory is managed by
the page allocator and the memblock.reserved is unused, so the only purpose
of the memblock_free() call is to keep track of initrd memory for debugging
and accounting.
Without the memblock_free() call the only difference between arm64 and the
generic versions of free_initrd_mem() is the memory poisoning.
Move memblock_free() call to the generic code, enable it there
for the architectures that define ARCH_KEEP_MEMBLOCK and use the generic
implementation of free_initrd_mem() on arm64.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
v2 changes:
* add memblock_free() to the generic free_initrd_mem()
* rebase on the current upstream
arch/arm64/mm/init.c | 12 ------------
init/initramfs.c | 4 ++++
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 45c00a5..87a0e3b 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -580,18 +580,6 @@ void free_initmem(void)
unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
}
-#ifdef CONFIG_BLK_DEV_INITRD
-void __init free_initrd_mem(unsigned long start, unsigned long end)
-{
- unsigned long aligned_start, aligned_end;
-
- aligned_start = __virt_to_phys(start) & PAGE_MASK;
- aligned_end = PAGE_ALIGN(__virt_to_phys(end));
- memblock_free(aligned_start, aligned_end - aligned_start);
- free_reserved_area((void *)start, (void *)end, 0, "initrd");
-}
-#endif
-
/*
* Dump out memory limit information on panic.
*/
diff --git a/init/initramfs.c b/init/initramfs.c
index c47dad0..403c6a0 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -531,6 +531,10 @@ void __weak free_initrd_mem(unsigned long start, unsigned long end)
{
free_reserved_area((void *)start, (void *)end, POISON_FREE_INITMEM,
"initrd");
+
+#ifdef CONFIG_ARCH_KEEP_MEMBLOCK
+ memblock_free(__virt_to_phys(start), end - start);
+#endif
}
#ifdef CONFIG_KEXEC_CORE
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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