* [PATCH v1 0/2] support to set VSESR_EL2 by user space
From: Dongjiu Geng @ 2018-05-31 13:08 UTC (permalink / raw)
To: linux-arm-kernel
This series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
1. Detect whether KVM can set set guest SError syndrome
2. Support to Set VSESR_EL2 and inject SError by user space.
3. Support live migration to keep SError pending state and VSESR_EL2 value
The user space patch is here: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06965.html
Dongjiu Geng (2):
arm64: KVM: export the capability to set guest SError syndrome
arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
Documentation/virtual/kvm/api.txt | 42 +++++++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/kvm/guest.c | 12 +++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 ++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++
arch/arm64/kvm/guest.c | 36 +++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 7 +++++-
arch/arm64/kvm/reset.c | 4 ++++
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 21 ++++++++++++++++++
11 files changed, 150 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v1 1/2] arm64: KVM: export the capability to set guest SError syndrome
From: Dongjiu Geng @ 2018-05-31 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527772139-19665-1-git-send-email-gengdongjiu@huawei.com>
For the arm64 RAS Extension, user space can inject a virtual-SError
with specified ESR. So user space needs to know whether KVM support
to inject such SError, this interface adds this query for this capability.
KVM will check whether system support RAS Extension, if supported, KVM
returns true to user space, otherwise returns false.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
---
Documentation/virtual/kvm/api.txt | 11 +++++++++++
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 758bf40..fdac969 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4603,3 +4603,14 @@ Architectures: s390
This capability indicates that kvm will implement the interfaces to handle
reset, migration and nested KVM for branch prediction blocking. The stfle
facility 82 should not be provided to the guest without this capability.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify the syndrome value reported
+to the guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the ESR
+syndrome, it can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be reported
+in ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+ case KVM_CAP_ARM_INJECT_SERROR_ESR:
+ r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+ break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b02c41e..e88f976 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -948,6 +948,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_BPB 152
#define KVM_CAP_GET_MSR_FEATURES 153
#define KVM_CAP_HYPERV_EVENTFD 154
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 155
#ifdef KVM_CAP_IRQ_ROUTING
--
2.7.4
^ permalink raw reply related
* [PATCH v1 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: Dongjiu Geng @ 2018-05-31 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527772139-19665-1-git-send-email-gengdongjiu@huawei.com>
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes, user space can get/set
the SError exception state to do migrate/snapshot/suspend.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
--
this series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
change since V12:
1. change (vcpu->arch.hcr_el2 & HCR_VSE) to !!(vcpu->arch.hcr_el2 & HCR_VSE) in kvm_arm_vcpu_get_events()
Change since V11:
Address James's comments, thanks James
1. Align the struct of kvm_vcpu_events to 64 bytes
2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
4. Change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
---
Documentation/virtual/kvm/api.txt | 31 ++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/kvm/guest.c | 12 ++++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 +++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++++
arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 7 ++++++-
arch/arm64/kvm/reset.c | 1 +
virt/kvm/arm/arm.c | 21 +++++++++++++++++++++
10 files changed, 135 insertions(+), 4 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index fdac969..8896737 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -835,11 +835,13 @@ struct kvm_clock_data {
Capability: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (out)
Returns: 0 on success, -1 on error
+X86:
+
Gets currently pending exceptions, interrupts, and NMIs as well as related
states of the vcpu.
@@ -881,15 +883,32 @@ Only two fields are defined in the flags field:
- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
smi contains a valid state.
+ARM, ARM64:
+
+Gets currently pending SError exceptions as well as related states of the vcpu.
+
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
4.32 KVM_SET_VCPU_EVENTS
-Capability: KVM_CAP_VCPU_EVENTS
+Capebility: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (in)
Returns: 0 on success, -1 on error
+X86:
+
Set pending exceptions, interrupts, and NMIs as well as related states of the
vcpu.
@@ -910,6 +929,12 @@ shall be written into the VCPU.
KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
+ARM, ARM64:
+
+Set pending SError exceptions as well as related states of the vcpu.
+
+See KVM_GET_VCPU_EVENTS for the data structure.
+
4.33 KVM_GET_DEBUGREGS
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index c7c28c8..39f9901 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -213,6 +213,12 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
unsigned long kvm_call_hyp(void *hypfn, ...);
void force_vm_exit(const cpumask_t *mask);
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index a18f33e..c685f0e 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -261,6 +261,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 1dab3a9..18f61ff 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -81,6 +81,11 @@ static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
return (unsigned long *)&vcpu->arch.hcr_el2;
}
+static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.vsesr_el2;
+}
+
static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
{
vcpu->arch.vsesr_el2 = vsesr;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 469de8a..357304a 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -335,6 +335,11 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
@@ -363,6 +368,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
void __kvm_set_tpidr_el2(u64 tpidr_el2);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 04b3256..df4faee 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -39,6 +39,7 @@
#define __KVM_HAVE_GUEST_DEBUG
#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_READONLY_MEM
+#define __KVM_HAVE_VCPU_EVENTS
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
@@ -153,6 +154,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 56a0260..71d3841 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -289,6 +289,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ events->exception.serror_pending = !!(vcpu->arch.hcr_el2 & HCR_VSE);
+ events->exception.serror_has_esr =
+ cpus_have_const_cap(ARM64_HAS_RAS_EXTN) &&
+ (!!vcpu_get_vsesr(vcpu));
+
+ if (events->exception.serror_pending &&
+ events->exception.serror_has_esr)
+ events->exception.serror_esr = vcpu_get_vsesr(vcpu);
+ else
+ events->exception.serror_esr = 0;
+
+ return 0;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ bool serror_pending = events->exception.serror_pending;
+ bool has_esr = events->exception.serror_has_esr;
+
+ if (serror_pending && has_esr) {
+ if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
+ return -EINVAL;
+
+ kvm_set_sei_esr(vcpu, events->exception.serror_esr);
+
+ } else if (serror_pending) {
+ kvm_inject_vabt(vcpu);
+ }
+
+ return 0;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
unsigned long implementor = read_cpuid_implementor();
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index d8e7165..9e0ca56 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
{
- vcpu_set_vsesr(vcpu, esr);
+ vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
*vcpu_hcr(vcpu) |= HCR_VSE;
}
@@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu)
{
pend_guest_serror(vcpu, ESR_ELx_ISV);
}
+
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome)
+{
+ pend_guest_serror(vcpu, syndrome);
+}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 38c8a64..20e919a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
+ case KVM_CAP_VCPU_EVENTS:
r = 1;
break;
default:
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index a4c1b76..8b43968 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1107,6 +1107,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
r = kvm_arm_vcpu_has_attr(vcpu, &attr);
break;
}
+ case KVM_GET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ memset(&events, 0, sizeof(events));
+ if (kvm_arm_vcpu_get_events(vcpu, &events))
+ return -EINVAL;
+
+ if (copy_to_user(argp, &events, sizeof(events)))
+ return -EFAULT;
+
+ return 0;
+ }
+ case KVM_SET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (copy_from_user(&events, argp,
+ sizeof(struct kvm_vcpu_events)))
+ return -EFAULT;
+
+ return kvm_arm_vcpu_set_events(vcpu, &events);
+ }
default:
r = -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH] media: helene: fix tuning frequency of satellite
From: Abylay Ospan @ 2018-05-31 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <004201d3f8bb$629d38c0$27d7aa40$@socionext.com>
ok, got it !
2018-05-31 4:43 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> Hello Abylay,
>
> I got a mistake in this patch.
>
> DTV_FREQUENCY for satellite delivery systems, the frequency is in 'kHz' not 'Hz',
> so original code is correct. Sorry for confusing...
>
>
> Regards,
> --
> Katsuhiro Suzuki
>
>
>> -----Original Message-----
>> From: Abylay Ospan <aospan@netup.ru>
>> Sent: Wednesday, May 16, 2018 7:58 PM
>> To: Suzuki, Katsuhiro/?? ?? <suzuki.katsuhiro@socionext.com>
>> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; linux-media
>> <linux-media@vger.kernel.org>; Masami Hiramatsu <masami.hiramatsu@linaro.org>;
>> Jassi Brar <jaswinder.singh@linaro.org>; linux-arm-kernel at lists.infradead.org;
>> linux-kernel at vger.kernel.org
>> Subject: Re: [PATCH] media: helene: fix tuning frequency of satellite
>>
>> True.
>> I'm curious but how did it worked before ...
>> Which hardware (dvb adapter) are you using ?
>>
>> 2018-05-16 4:41 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
>> > This patch fixes tuning frequency of satellite to kHz. That as same
>> > as terrestrial one.
>> >
>> > Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
>> > ---
>> > drivers/media/dvb-frontends/helene.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/media/dvb-frontends/helene.c
>> b/drivers/media/dvb-frontends/helene.c
>> > index 04033f0c278b..0a4f312c4368 100644
>> > --- a/drivers/media/dvb-frontends/helene.c
>> > +++ b/drivers/media/dvb-frontends/helene.c
>> > @@ -523,7 +523,7 @@ static int helene_set_params_s(struct dvb_frontend *fe)
>> > enum helene_tv_system_t tv_system;
>> > struct dtv_frontend_properties *p = &fe->dtv_property_cache;
>> > struct helene_priv *priv = fe->tuner_priv;
>> > - int frequencykHz = p->frequency;
>> > + int frequencykHz = p->frequency / 1000;
>> > uint32_t frequency4kHz = 0;
>> > u32 symbol_rate = p->symbol_rate/1000;
>> >
>> > --
>> > 2.17.0
>> >
>>
>>
>>
>> --
>> Abylay Ospan,
>> NetUP Inc.
>> http://www.netup.tv
>
>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Tero Kristo @ 2018-05-31 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e7e3ade1-76b7-f216-ece5-bd64a55cede6@ti.com>
On 31/05/18 13:14, Faiz Abbas wrote:
> Hi,
>
> On Thursday 31 May 2018 09:33 AM, Rob Herring wrote:
>> On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
>>> Add clkctrl data for the m_can clocks and register it within the
> ...
>>>
>>> diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
>>> index 5e1061b15aed..d7549c57cac3 100644
>>> --- a/include/dt-bindings/clock/dra7.h
>>> +++ b/include/dt-bindings/clock/dra7.h
>>> @@ -168,5 +168,6 @@
>>> #define DRA7_COUNTER_32K_CLKCTRL DRA7_CLKCTRL_INDEX(0x50)
>>> #define DRA7_UART10_CLKCTRL DRA7_CLKCTRL_INDEX(0x80)
>>> #define DRA7_DCAN1_CLKCTRL DRA7_CLKCTRL_INDEX(0x88)
>>> +#define DRA7_ADC_CLKCTRL DRA7_CLKCTRL_INDEX(0xa0)
>>
>> ADC and mcan are the same thing?
>>
>
> The register to control MCAN clocks is called ADC_CLKCTRL, Yes.
Is there any reason for this or is that just a documentation bug?
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH 0/3] Initial Spectre variant 1 patches
From: Russell King - ARM Linux @ 2018-05-31 13:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series adds initial support for the Spectre variant 1 workarounds
to the kernel. This does _not_ cover the user accessors, which are
still in development.
The series adds support for the array_index_mask_nospec() macro, used
by generic kernel code to mask out of bounds pointers, and also adds
the syscall table hardening.
arch/arm/include/asm/assembler.h | 8 ++++++++
arch/arm/include/asm/barrier.h | 31 +++++++++++++++++++++++++++++++
arch/arm/kernel/entry-common.S | 14 +++-----------
arch/arm/kernel/entry-header.S | 25 +++++++++++++++++++++++++
4 files changed, 67 insertions(+), 11 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/3] ARM: spectre-v1: add speculation barrier (csdb) macros
From: Russell King @ 2018-05-31 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531133047.GS17671@n2100.armlinux.org.uk>
Add assembly and C macros for the new CSDB instruction.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/assembler.h | 8 ++++++++
arch/arm/include/asm/barrier.h | 13 +++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index bc8d4bbd82e2..ef1386b1af9b 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -447,6 +447,14 @@ THUMB( orr \reg , \reg , #PSR_T_BIT )
.size \name , . - \name
.endm
+ .macro csdb
+#ifdef CONFIG_THUMB2_KERNEL
+ .inst.w 0xf3af8014
+#else
+ .inst 0xe320f014
+#endif
+ .endm
+
.macro check_uaccess, addr:req, size:req, limit:req, tmp:req, bad:req
#ifndef CONFIG_CPU_USE_DOMAINS
adds \tmp, \addr, #\size - 1
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 40f5c410fd8c..3d9c1d4b7e75 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -17,6 +17,12 @@
#define isb(option) __asm__ __volatile__ ("isb " #option : : : "memory")
#define dsb(option) __asm__ __volatile__ ("dsb " #option : : : "memory")
#define dmb(option) __asm__ __volatile__ ("dmb " #option : : : "memory")
+#ifdef CONFIG_THUMB2_KERNEL
+#define CSDB ".inst.w 0xf3af8014"
+#else
+#define CSDB ".inst 0xe320f014"
+#endif
+#define csdb() __asm__ __volatile__(CSDB : : : "memory")
#elif defined(CONFIG_CPU_XSC3) || __LINUX_ARM_ARCH__ == 6
#define isb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c5, 4" \
: : "r" (0) : "memory")
@@ -37,6 +43,13 @@
#define dmb(x) __asm__ __volatile__ ("" : : : "memory")
#endif
+#ifndef CSDB
+#define CSDB
+#endif
+#ifndef csdb
+#define csdb()
+#endif
+
#ifdef CONFIG_ARM_HEAVY_MB
extern void (*soc_mb)(void);
extern void arm_heavy_mb(void);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: spectre-v1: add array_index_mask_nospec() implementation
From: Russell King @ 2018-05-31 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531133047.GS17671@n2100.armlinux.org.uk>
Add an implementation of the array_index_mask_nospec() function for
mitigating Spectre variant 1 throughout the kernel.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/barrier.h | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 3d9c1d4b7e75..a89adcf53b99 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -76,6 +76,24 @@ extern void arm_heavy_mb(void);
#define __smp_rmb() __smp_mb()
#define __smp_wmb() dmb(ishst)
+#ifdef CONFIG_CPU_SPECTRE
+static inline unsigned long array_index_mask_nospec(unsigned long idx,
+ unsigned long sz)
+{
+ unsigned long mask;
+
+ asm( "cmp %1, %2\n"
+ " sbc %0, %1, %1\n"
+ CSDB
+ : "=r" (mask)
+ : "r" (idx), "Ir" (sz)
+ : "cc");
+
+ return mask;
+}
+#define array_index_mask_nospec array_index_mask_nospec
+#endif
+
#include <asm-generic/barrier.h>
#endif /* !__ASSEMBLY__ */
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: spectre-v1: fix syscall entry
From: Russell King @ 2018-05-31 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531133047.GS17671@n2100.armlinux.org.uk>
Prevent speculation at the syscall table decoding by clamping the index
used to zero on invalid system call numbers, and using the csdb
speculative barrier.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/kernel/entry-common.S | 14 +++-----------
| 25 +++++++++++++++++++++++++
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 3c4f88701f22..78b9f20dd6a3 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -242,9 +242,7 @@ ENTRY(vector_swi)
tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls?
bne __sys_trace
- cmp scno, #NR_syscalls @ check upper syscall limit
- badr lr, ret_fast_syscall @ return address
- ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
+ invoke_syscall tbl, scno, r10, ret_fast_syscall
add r1, sp, #S_OFF
2: cmp scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE)
@@ -278,14 +276,8 @@ ENDPROC(vector_swi)
mov r1, scno
add r0, sp, #S_OFF
bl syscall_trace_enter
-
- badr lr, __sys_trace_return @ return address
- mov scno, r0 @ syscall number (possibly new)
- add r1, sp, #S_R0 + S_OFF @ pointer to regs
- cmp scno, #NR_syscalls @ check upper syscall limit
- ldmccia r1, {r0 - r6} @ have to reload r0 - r6
- stmccia sp, {r4, r5} @ and update the stack args
- ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
+ mov scno, r0
+ invoke_syscall tbl, scno, r10, __sys_trace_return, reload=1
cmp scno, #-1 @ skip the syscall?
bne 2b
add sp, sp, #S_OFF @ restore stack
--git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index 0f07579af472..773424843d6e 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -378,6 +378,31 @@
#endif
.endm
+ .macro invoke_syscall, table, nr, tmp, ret, reload=0
+#ifdef CONFIG_CPU_SPECTRE
+ mov \tmp, \nr
+ cmp \tmp, #NR_syscalls @ check upper syscall limit
+ movcs \tmp, #0
+ csdb
+ badr lr, \ret @ return address
+ .if \reload
+ add r1, sp, #S_R0 + S_OFF @ pointer to regs
+ ldmccia r1, {r0 - r6} @ reload r0-r6
+ stmccia sp, {r4, r5} @ update stack arguments
+ .endif
+ ldrcc pc, [\table, \tmp, lsl #2] @ call sys_* routine
+#else
+ cmp \nr, #NR_syscalls @ check upper syscall limit
+ badr lr, \ret @ return address
+ .if \reload
+ add r1, sp, #S_R0 + S_OFF @ pointer to regs
+ ldmccia r1, {r0 - r6} @ reload r0-r6
+ stmccia sp, {r4, r5} @ update stack arguments
+ .endif
+ ldrcc pc, [\table, \nr, lsl #2] @ call sys_* routine
+#endif
+ .endm
+
/*
* These are the registers used in the syscall handler, and allow us to
* have in theory up to 7 arguments to a function - r0 to r6.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Tony Lindgren @ 2018-05-31 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be0fd711-c44b-dbe2-648f-08aa88c7aec4@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180531 11:27]:
> On Thursday 31 May 2018 09:36 AM, Rob Herring wrote:
> > On Wed, May 30, 2018 at 07:41:32PM +0530, Faiz Abbas wrote:
> >> --- a/arch/arm/boot/dts/dra76x.dtsi
> >> +++ b/arch/arm/boot/dts/dra76x.dtsi
> >> @@ -11,6 +11,25 @@
> >> / {
> >> compatible = "ti,dra762", "ti,dra7";
> >>
> >> + ocp {
> >> +
> >> + target-module at 0x42c00000 {
> >
> > Build your dtb with W=1 and fix warnings you add (drop '0x').
>
> Sure, Will fix this.
> >
> > This is a CAN bus controller? If so, then use 'can' for node name.
>
> Yes but I am using m_can along the lines of dcan in other boards (For
> example, see arch/arm/boot/dts/am33xx.dtsi:1046). Are you saying all CAN
> controllers should only be called can?
The module should be target-module at 42c00000 and the child(ren)
can at 1a00 or mcan at 1a00 if mcan is different from can.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Tony Lindgren @ 2018-05-31 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2361da91-659d-1aaa-0ab8-d1473bc3a71a@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180531 10:22]:
> On Wednesday 30 May 2018 08:34 PM, Tony Lindgren wrote:
> > Looks good to me except I think the reset won't do anything currently
> > with ti-sysc.c unless you specfify also "ti,hwmods" for the module?
> >
> > Can you please check? It might be worth adding the reset function to
> > ti-sysc.c for non "ti,hwmods" case and that just might remove the
> > need for any hwmod code for this module.
> >
>
> If I understand correctly, this involves adding a (*reset_module) in
> ti_sysc_platform_data and defining a ti_sysc_reset_module() in ti-sysc.c
> similar to ti_sysc_idle_module(). Right?
Well try moving "ti,hwmods" to the module level first. Then reset will
happen with enable.
Then for simple cases we can add reset directly to ti-sysc.c without
pdata callbacks and and drop "ti,hwmods". For more complex cases we
need to use reset-simple for the RSTCTRL registers.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/4] arm64: capabilities: add nopti command line argument
From: Mark Langsdorf @ 2018-05-31 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b1b39e3-38ab-848a-a1d3-d23db85b0e14@arm.com>
On 05/30/2018 03:59 AM, Suzuki K Poulose wrote:
>
>
> Hi Mark,
>
> On 24/05/18 20:09, Mark Langsdorf wrote:
>> The x86 kernel and the documentation use 'nopti' as the kernel command
>> line argument to disable kernel page table isolation, so add nopti to
>> the arm64 kernel for compatibility.
>>
>> Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
>> ---
>> ? Documentation/admin-guide/kernel-parameters.txt |? 6 +++---
>> ? arch/arm64/kernel/cpufeature.c????????????????? | 11 ++++++++++-
>> ? 2 files changed, 13 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index f2040d4..a987725 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -3342,8 +3342,8 @@
>> ????? pt.??????? [PARIDE]
>> ????????????? See Documentation/blockdev/paride.txt.
>> -??? pti=??????? [X86_64] Control Page Table Isolation of user and
>> -??????????? kernel address spaces.? Disabling this feature
>> +??? pti=??????? [X86_64, ARM64] Control Page Table Isolation of user
>> +??????????? and kernel address spaces.? Disabling this feature
>> ????????????? removes hardening, but improves performance of
>> ????????????? system calls and interrupts.
>
> ...
>
>> @@ -3354,7 +3354,7 @@
>> ????????????? Not specifying this option is equivalent to pti=auto.
>> -??? nopti??????? [X86_64]
>> +??? nopti??????? [X86_64, ARM64]
>> ????????????? Equivalent to pti=off
>> ????? pty.legacy_count=
>> diff --git a/arch/arm64/kernel/cpufeature.c
>> b/arch/arm64/kernel/cpufeature.c
>> index 9d1b06d..7c5d8712 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -934,10 +934,19 @@ static int __init parse_kpti(char *str)
>> ????? if (ret)
>> ????????? return ret;
>> -??? __kpti_forced = enabled ? 1 : -1;
>> +??? if (!__kpti_forced)
>> +??????? __kpti_forced = enabled ? 1 : -1;
>> ????? return 0;
>> ? }
>> ? __setup("kpti=", parse_kpti);
>
> The arm64 kernel parameter is named "kpti", while the Documentation
> update above says "pti". We may want to keep both in sync here.
Good point. I think I will add a new kpti entry for ARM64 in
kernel-parameters. Then the docs match the code, instead of trying to
match the code to the docs.
--Mark Langsdorf
^ permalink raw reply
* [PATCH 0/7] add non-strict mode support for arm-smmu-v3
From: Hanjun Guo @ 2018-05-31 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d65f87a4-db61-3cd2-1a6f-0322025840a8@arm.com>
Hi Robin,
On 2018/5/31 19:24, Robin Murphy wrote:
> On 31/05/18 08:42, Zhen Lei wrote:
>> In common, a IOMMU unmap operation follow the below steps:
>> 1. remove the mapping in page table of the specified iova range
>> 2. execute tlbi command to invalid the mapping which is cached in TLB
>> 3. wait for the above tlbi operation to be finished
>> 4. free the IOVA resource
>> 5. free the physical memory resource
>>
>> This maybe a problem when unmap is very frequently, the combination of tlbi
>> and wait operation will consume a lot of time. A feasible method is put off
>> tlbi and iova-free operation, when accumulating to a certain number or
>> reaching a specified time, execute only one tlbi_all command to clean up
>> TLB, then free the backup IOVAs. Mark as non-strict mode.
>>
>> But it must be noted that, although the mapping has already been removed in
>> the page table, it maybe still exist in TLB. And the freed physical memory
>> may also be reused for others. So a attacker can persistent access to memory
>> based on the just freed IOVA, to obtain sensible data or corrupt memory. So
>> the VFIO should always choose the strict mode.
>>
>> Some may consider put off physical memory free also, that will still follow
>> strict mode. But for the map_sg cases, the memory allocation is not controlled
>> by IOMMU APIs, so it is not enforceable.
>>
>> Fortunately, Intel and AMD have already applied the non-strict mode, and put
>> queue_iova() operation into the common file dma-iommu.c., and my work is based
>> on it. The difference is that arm-smmu-v3 driver will call IOMMU common APIs to
>> unmap, but Intel and AMD IOMMU drivers are not.
>>
>> Below is the performance data of strict vs non-strict for NVMe device:
>> Randomly Read? IOPS: 146K(strict) vs 573K(non-strict)
>> Randomly Write IOPS: 143K(strict) vs 513K(non-strict)
>
> What hardware is this on? If it's SMMUv3 without MSIs (e.g. D05), then you'll still be using the rubbish globally-blocking sync implementation. If that is the case, I'd be very interested to see how much there is to gain from just improving that - I've had a patch kicking around for a while[1] (also on a rebased branch at [2]), but don't have the means for serious performance testing.
The hardware is the new D06 which the SMMU with MSIs,
it's not D05 :)
Thanks
Hanjun
^ permalink raw reply
* [PATCH v2 4/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
From: Tony Lindgren @ 2018-05-31 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b627ab6-59f1-4a4f-42d2-5d6846adfe0b@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180531 10:17]:
> Hi,
>
> On Wednesday 30 May 2018 08:27 PM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
> >> The dra76x MCAN generic interconnect module has a its own
> >> format for the bits in the control registers.
> ...
> >> static int sysc_init_pdata(struct sysc *ddata)
> >> {
> >> struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
> >> @@ -1441,6 +1457,7 @@ static const struct of_device_id sysc_match[] = {
> >> { .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
> >> { .compatible = "ti,sysc-usb-host-fs",
> >> .data = &sysc_omap4_usb_host_fs, },
> >> + { .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
> >> { },
> >> };
> >
> > Looks good to me. And presumably you checked that no other dra7 modules
> > use sysconfig register bit layout like this?
> >
>
> As far as I could see, Yes.
OK thanks for checking it.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/2] arm64/drivers: avoid alloc memory on offline node
From: Hanjun Guo @ 2018-05-31 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527768879-88161-1-git-send-email-xiexiuqi@huawei.com>
Hi Xiuqi,
On 2018/5/31 20:14, Xie XiuQi wrote:
> A numa system may return node which is not online.
> For example, a numa node:
> 1) without memory
> 2) NR_CPUS is very small, and the cpus on the node are not brought up
I think adding detail info will be easy to be understood:
- NUMA node will be built if CPUs and (or) memory are valid on this NUMA node;
- But if we boot the system with memory-less node and also with CONFIG_NR_CPUS
less than CPUs in SRAT, for example, 64 CPUs total with 4 NUMA nodes, 16 CPUs
on each NUMA node, if we boot with CONFIG_NR_CPUS=48, then we will not built
numa node for node 3, but with devices on that numa node, alloc memory will
be panic because NUMA node 3 is not a valid node.
>
> In this situation, we use NUMA_NO_NODE to avoid oops.
[snip]
>
> Xie XiuQi (2):
> arm64: avoid alloc memory on offline node
> drivers: check numa node's online status in dev_to_node
I think we still missing devices like SMMU, ITS, so how about check
the numa node online in the core memory allocation such as kmalloc_node()?
Thanks
Hanjun
^ permalink raw reply
* [PATCH 00/12] introduce support for early platform drivers
From: Tony Lindgren @ 2018-05-31 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUY+-_72DHg9Tim2d4E24k5KskQxm52bHSyrSYLbZDr2g@mail.gmail.com>
* Geert Uytterhoeven <geert@linux-m68k.org> [180531 06:45]:
> Yes, they should all be drivers.
>
> Assuming clocksources, clockevents, or primary interrupt controllers are
> special, and thus forcing everyone to use OF_DECLARE for the whole
> subsystem, doesn't fly everywhere.
>
> Clockevents and interrupt controllers can have a module clock.
> All three can be part of a PM Domain, which requires a struct device to
> be handled properly.
I agree it sure would be nice to have all these as drivers. I believe
SoC specific clockevent using SoC specific clocks is the reason why some
clocks cannot currently be drivers.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/3] ARM: spectre-v1: add speculation barrier (csdb) macros
From: Mark Rutland @ 2018-05-31 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fONfc-000708-MX@rmk-PC.armlinux.org.uk>
On Thu, May 31, 2018 at 02:31:12PM +0100, Russell King wrote:
> Add assembly and C macros for the new CSDB instruction.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Looks correct to me per the Cache Speculation Side-chaneels 2.1
document.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm/include/asm/assembler.h | 8 ++++++++
> arch/arm/include/asm/barrier.h | 13 +++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index bc8d4bbd82e2..ef1386b1af9b 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -447,6 +447,14 @@ THUMB( orr \reg , \reg , #PSR_T_BIT )
> .size \name , . - \name
> .endm
>
> + .macro csdb
> +#ifdef CONFIG_THUMB2_KERNEL
> + .inst.w 0xf3af8014
> +#else
> + .inst 0xe320f014
> +#endif
> + .endm
> +
> .macro check_uaccess, addr:req, size:req, limit:req, tmp:req, bad:req
> #ifndef CONFIG_CPU_USE_DOMAINS
> adds \tmp, \addr, #\size - 1
> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
> index 40f5c410fd8c..3d9c1d4b7e75 100644
> --- a/arch/arm/include/asm/barrier.h
> +++ b/arch/arm/include/asm/barrier.h
> @@ -17,6 +17,12 @@
> #define isb(option) __asm__ __volatile__ ("isb " #option : : : "memory")
> #define dsb(option) __asm__ __volatile__ ("dsb " #option : : : "memory")
> #define dmb(option) __asm__ __volatile__ ("dmb " #option : : : "memory")
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define CSDB ".inst.w 0xf3af8014"
> +#else
> +#define CSDB ".inst 0xe320f014"
> +#endif
> +#define csdb() __asm__ __volatile__(CSDB : : : "memory")
> #elif defined(CONFIG_CPU_XSC3) || __LINUX_ARM_ARCH__ == 6
> #define isb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c5, 4" \
> : : "r" (0) : "memory")
> @@ -37,6 +43,13 @@
> #define dmb(x) __asm__ __volatile__ ("" : : : "memory")
> #endif
>
> +#ifndef CSDB
> +#define CSDB
> +#endif
> +#ifndef csdb
> +#define csdb()
> +#endif
> +
> #ifdef CONFIG_ARM_HEAVY_MB
> extern void (*soc_mb)(void);
> extern void arm_heavy_mb(void);
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Rob Herring @ 2018-05-31 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4f2e6e6a-df3a-b645-093c-b4467b3aa843@microchip.com>
On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
<codrin.ciubotariu@microchip.com> wrote:
> On 31.05.2018 03:58, Rob Herring wrote:
>>
>> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>>>
>>> The I2S mux clock can be used to select the I2S input clock. The
>>> available parents are the peripheral and the generated clocks.
>>>
>>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>>> ---
>>> .../devicetree/bindings/clock/at91-clock.txt | 34
>>> ++++++++++++++++++++++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> index 51c259a..1c46b3c 100644
>>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> @@ -90,6 +90,8 @@ Required properties:
>>> "atmel,sama5d2-clk-audio-pll-pmc"
>>> at91 audio pll output on AUDIOPLLCLK that feeds the PMC
>>> and can be used by peripheral clock or generic clock
>>> + "atmel,sama5d2-clk-i2s-mux":
>>> + at91 I2S clock source selection
>>
>>
>> Is this boolean or takes some values. If latter, what are valid values?
>
>
> This is the compatible string of the clock driver.
Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
still a plan to fix this?
>>> Required properties for SCKC node:
>>> - reg : defines the IO memory reserved for the SCKC.
>>> @@ -507,3 +509,35 @@ For example:
>>> atmel,clk-output-range = <0 83000000>;
>>> };
>>> };
>>> +
>>> +Required properties for I2S mux clocks:
>>> +- #size-cells : shall be 0 (reg is used to encode I2S bus id).
>>> +- #address-cells : shall be 1 (reg is used to encode I2S bus id).
>>> +- name: device tree node describing a specific mux clock.
>>> + * #clock-cells : from common clock binding; shall be set to 0.
>>> + * clocks : shall be the mux clock parent phandles; shall be 2
>>> phandles:
>>> + peripheral and generated clock; the first phandle shall belong
>>> to the
>>> + peripheral clock and the second one shall belong to the
>>> generated
>>> + clock; "clock-indices" property can be user to specify
>>> + the correct order.
>>> + * reg: I2S bus id of the corresponding mux clock.
>>> + e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
>>> +
>>> +For example:
>>> + i2s_clkmux {
>>
>>
>> What is this a child of?
>
>
> It is a child of PMC node, since both parent clocks are generated by PMC.
>
>>
>>> + compatible = "atmel,sama5d2-clk-i2s-mux";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>
>>
>> How do you address this block? My guess is you don't because it is just
>> part of some other block and you are just creating this node to
>> instantiate a driver. Just make the node for the actual h/w block a
>> clock provider and define the clock ids (0 and 1).
>
>
> This block is not addressed, but its children are. The register we access in
> this driver is not part of other block. It's a SFR register, accessed
> through syscon and it has nothing to do with the I2S IP (see SAMA5D2 DS,
> page 1256, fig. 44-1: I2SC Block Diagram) that is the consumer of this
> clock. Adding a clock-id property in the I2S node would be just like v3 of
> this series, with the difference that we use clock-id instead of alias id to
> set the clock parent, which is not how you suggested back then.
I wasn't suggesting a clock-id property, but a clock specifier (i.e.
make #clock-cells 1).
But AT91 clocks are all a mess, so I don't know what to tell you.
Rob
^ permalink raw reply
* [PATCH 2/3] ARM: spectre-v1: add array_index_mask_nospec() implementation
From: Mark Rutland @ 2018-05-31 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fONfh-00070F-Tw@rmk-PC.armlinux.org.uk>
On Thu, May 31, 2018 at 02:31:17PM +0100, Russell King wrote:
> Add an implementation of the array_index_mask_nospec() function for
> mitigating Spectre variant 1 throughout the kernel.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> arch/arm/include/asm/barrier.h | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
> index 3d9c1d4b7e75..a89adcf53b99 100644
> --- a/arch/arm/include/asm/barrier.h
> +++ b/arch/arm/include/asm/barrier.h
> @@ -76,6 +76,24 @@ extern void arm_heavy_mb(void);
> #define __smp_rmb() __smp_mb()
> #define __smp_wmb() dmb(ishst)
>
> +#ifdef CONFIG_CPU_SPECTRE
> +static inline unsigned long array_index_mask_nospec(unsigned long idx,
> + unsigned long sz)
> +{
> + unsigned long mask;
> +
> + asm( "cmp %1, %2\n"
> + " sbc %0, %1, %1\n"
> + CSDB
> + : "=r" (mask)
> + : "r" (idx), "Ir" (sz)
> + : "cc");
> +
> + return mask;
> +}
> +#define array_index_mask_nospec array_index_mask_nospec
> +#endif
I believe that the asm should be volatile, otherwise there are cases
where the compiler could remove an invocation that's redundant under
architectural execution, but required under speculation [1].
With that made volatile:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
[1] https://lkml.kernel.org/r/20180530060546.jnjoltsturoduohh at salmiak
^ permalink raw reply
* [PATCH 0/7] add non-strict mode support for arm-smmu-v3
From: Robin Murphy @ 2018-05-31 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <96cc25b9-b21f-6067-384d-f52e6b8b25e7@huawei.com>
On 31/05/18 14:49, Hanjun Guo wrote:
> Hi Robin,
>
> On 2018/5/31 19:24, Robin Murphy wrote:
>> On 31/05/18 08:42, Zhen Lei wrote:
>>> In common, a IOMMU unmap operation follow the below steps:
>>> 1. remove the mapping in page table of the specified iova range
>>> 2. execute tlbi command to invalid the mapping which is cached in TLB
>>> 3. wait for the above tlbi operation to be finished
>>> 4. free the IOVA resource
>>> 5. free the physical memory resource
>>>
>>> This maybe a problem when unmap is very frequently, the combination of tlbi
>>> and wait operation will consume a lot of time. A feasible method is put off
>>> tlbi and iova-free operation, when accumulating to a certain number or
>>> reaching a specified time, execute only one tlbi_all command to clean up
>>> TLB, then free the backup IOVAs. Mark as non-strict mode.
>>>
>>> But it must be noted that, although the mapping has already been removed in
>>> the page table, it maybe still exist in TLB. And the freed physical memory
>>> may also be reused for others. So a attacker can persistent access to memory
>>> based on the just freed IOVA, to obtain sensible data or corrupt memory. So
>>> the VFIO should always choose the strict mode.
>>>
>>> Some may consider put off physical memory free also, that will still follow
>>> strict mode. But for the map_sg cases, the memory allocation is not controlled
>>> by IOMMU APIs, so it is not enforceable.
>>>
>>> Fortunately, Intel and AMD have already applied the non-strict mode, and put
>>> queue_iova() operation into the common file dma-iommu.c., and my work is based
>>> on it. The difference is that arm-smmu-v3 driver will call IOMMU common APIs to
>>> unmap, but Intel and AMD IOMMU drivers are not.
>>>
>>> Below is the performance data of strict vs non-strict for NVMe device:
>>> Randomly Read? IOPS: 146K(strict) vs 573K(non-strict)
>>> Randomly Write IOPS: 143K(strict) vs 513K(non-strict)
>>
>> What hardware is this on? If it's SMMUv3 without MSIs (e.g. D05), then you'll still be using the rubbish globally-blocking sync implementation. If that is the case, I'd be very interested to see how much there is to gain from just improving that - I've had a patch kicking around for a while[1] (also on a rebased branch at [2]), but don't have the means for serious performance testing.
>
> The hardware is the new D06 which the SMMU with MSIs,
Cool! Now that profiling is fairly useful since we got rid of most of
the locks, are you able to get an idea of how the overhead in the normal
case is distributed between arm_smmu_cmdq_insert_cmd() and
__arm_smmu_sync_poll_msi()? We're always trying to improve our
understanding of where command-queue-related overheads turn out to be in
practice, and there's still potentially room to do nicer things than
TLBI_NH_ALL ;)
Robin.
> it's not D05 :)
>
> Thanks
> Hanjun
>
^ permalink raw reply
* [PATCH 0/3] ARM: shmobile: apmu: Cleanups after legacy SMP fallback removal
From: Simon Horman @ 2018-05-31 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527693328-10559-1-git-send-email-geert+renesas@glider.be>
On Wed, May 30, 2018 at 05:15:25PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> Now the legacy SMP fallbacks for R-Car H2 and M2-W have been removed, a
> few more code cleanups can be applied.
>
> The third patch is a bit larger than I had hoped, due to the need to
> reshuffle a few functions in the absence of forward declarations.
>
> Tested on Lager (R-Car H2) and Koelsch (R-Car M2-W).
>
> Thanks!
>
> Geert Uytterhoeven (3):
> ARM: shmobile: apmu: Move cpu_leave_lowpower() to SUSPEND section
> ARM: shmobile: apmu: Remove obsolete shmobile_smp_apmu_prepare_cpus()
> ARM: shmobile: apmu: Remove platsmp-apmu.h
This looks fine but I will wait to see if there are other reviews before
applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Rob Herring @ 2018-05-31 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527737273-8387-3-git-send-email-djw@t-chip.com.cn>
On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
> From: Levin Du <djw@t-chip.com.cn>
>
> In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
> mute control, can also be used for general purpose. It is manipulated by
> the GRF_SOC_CON10 register.
>
> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>
> ---
>
> Changes in v3:
> - Change from general gpio-syscon to specific rk3328-gpio-mute
>
> Changes in v2:
> - Rename gpio_syscon10 to gpio_mute in doc
>
> Changes in v1:
> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> - Add doc rockchip,gpio-syscon.txt
>
> .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28 +++++++++++++++++++
> drivers/gpio/gpio-syscon.c | 31 ++++++++++++++++++++++
> 2 files changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> new file mode 100644
> index 0000000..10bc632
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> @@ -0,0 +1,28 @@
> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE pin.
> +
> +In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute
> +control, can also be used for general purpose. It is manipulated by the
> +GRF_SOC_CON10 register.
> +
> +Required properties:
> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
> +- gpio-controller: Marks the device node as a gpio controller.
> +- #gpio-cells: Should be 2. The first cell is the pin number and
> + the second cell is used to specify the gpio polarity:
> + 0 = Active high,
> + 1 = Active low.
> +
> +Example:
> +
> + grf: syscon at ff100000 {
> + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> +
> + gpio_mute: gpio-mute {
Node names should be generic:
gpio {
This also means you can't add another GPIO node in the future and
you'll have to live with "rockchip,rk3328-gpio-mute" covering more
than 1 GPIO if you do need to add more GPIOs.
> + compatible = "rockchip,rk3328-gpio-mute";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> + };
> +
> +Note: The gpio_mute node should be declared as the child of the GRF (General
> +Register File) node. The GPIO_MUTE pin is referred to as <&gpio_mute 0>.
This is wrong because you should have 2 cells. The phandle doesn't
count as a cell.
Rob
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Actions Semi S900 clk entries
From: Manivannan Sadhasivam @ 2018-05-31 15:23 UTC (permalink / raw)
To: linux-arm-kernel
Add S900 clk entries under ARCH_ACTIONS
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 48bfffe..964cd28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1143,12 +1143,14 @@ N: owl
F: arch/arm/mach-actions/
F: arch/arm/boot/dts/owl-*
F: arch/arm64/boot/dts/actions/
+F: drivers/clk/actions/
F: drivers/clocksource/owl-*
F: drivers/pinctrl/actions/*
F: drivers/soc/actions/
F: include/dt-bindings/power/owl-*
F: include/linux/soc/actions/
F: Documentation/devicetree/bindings/arm/actions.txt
+F: Documentation/devicetree/bindings/clock/actions,s900-cmu.txt
F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
F: Documentation/devicetree/bindings/power/actions,owl-sps.txt
F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Tony Lindgren @ 2018-05-31 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <98c989ca-0694-5150-f74b-35f3e4bf20c0@ti.com>
* Tero Kristo <t-kristo@ti.com> [180531 06:18]:
> On 30/05/18 18:54, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [180530 15:44]:
> > > On 30/05/18 18:28, Tony Lindgren wrote:
> > > > * Tero Kristo <t-kristo@ti.com> [180530 15:18]:
> > > > > For the OCP if part, I think that is still needed until we switch over to
> > > > > full sysc driver. clkctrl_offs you probably also need because that is used
> > > > > for mapping the omap_hwmod against a specific clkctrl clock. Those can be
> > > > > only removed once we are done with hwmod (or figure out some other way to
> > > > > assign the clkctrl clock to a hwmod.)
> > > >
> > > > Hmm might be worth testing. I thought your commit 70f05be32133
> > > > ("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
> > > > already parses the clkctrl from dts?
> > >
> > > It maps the clkctrl clock to be used by hwmod, if those are available. We
> > > didn't add any specific clock entries to DT for mapping the actual clkctrl
> > > clock without the hwmod_data hints yet though, as that was deemed temporary
> > > solution only due to transition to interconnect driver. I.e., you would need
> > > something like this in DT for every device node:
> > >
> > > &uart3 {
> > > clocks = <l4per_clkctrl UART3_CLK 0>;
> > > clock-names = "clkctrl";
> > > };
> > >
> > > ... which is currently not present.
> >
> > Hmm is that not the "fck" clkctrl clock we have already in
> > the dts files for the interconnect target modules?
>
> Oh okay, yeah, we could parse that one, but currently it is not done, and is
> not present for everything either I believe.
>
> > We can also use pdata callbacks to pass the clock node if
> > needed. But I guess I don't quite still understand what we
> > are missing :)
>
> So, what is missing is the glue logic only from the hwmod codebase. Right
> now this is not supported but should be relatively trivial thing to add if
> we really want to do this.
OK let's think about this a bit for v4.19 then.
Regards,
Tony
^ permalink raw reply
* [PATCH v4 2/7] clk: at91: add I2S clock mux driver
From: Stephen Boyd @ 2018-05-31 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527251668-31396-3-git-send-email-codrin.ciubotariu@microchip.com>
Quoting Codrin Ciubotariu (2018-05-25 05:34:23)
> This driver is a simple muxing driver that controls the
> I2S's clock input by using syscon/regmap to change the parrent.
s/parrent/parent/
> The available inputs can be Peripheral clock and Generated clock.
Why capitalize peripheral and generated?
>
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 1254bf9..903f23c 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -27,6 +27,7 @@ config SOC_SAMA5D2
> select HAVE_AT91_H32MX
> select HAVE_AT91_GENERATED_CLK
> select HAVE_AT91_AUDIO_PLL
> + select HAVE_AT91_I2S_MUX_CLK
> select PINCTRL_AT91PIO4
> help
> Select this if ou are using one of Microchip's SAMA5D2 family SoC.
> @@ -129,6 +130,9 @@ config HAVE_AT91_GENERATED_CLK
> config HAVE_AT91_AUDIO_PLL
> bool
>
> +config HAVE_AT91_I2S_MUX_CLK
> + bool
> +
> config SOC_SAM_V4_V5
> bool
>
I guess this is OK.
> diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
> index 082596f..facc169 100644
> --- a/drivers/clk/at91/Makefile
> +++ b/drivers/clk/at91/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_HAVE_AT91_USB_CLK) += clk-usb.o
> obj-$(CONFIG_HAVE_AT91_SMD) += clk-smd.o
> obj-$(CONFIG_HAVE_AT91_H32MX) += clk-h32mx.o
> obj-$(CONFIG_HAVE_AT91_GENERATED_CLK) += clk-generated.o
> +obj-$(CONFIG_HAVE_AT91_I2S_MUX_CLK) += clk-i2s-mux.o
> diff --git a/drivers/clk/at91/clk-i2s-mux.c b/drivers/clk/at91/clk-i2s-mux.c
> new file mode 100644
> index 0000000..2d56ded
> --- /dev/null
> +++ b/drivers/clk/at91/clk-i2s-mux.c
> @@ -0,0 +1,117 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2018 Microchip Technology Inc,
> + * Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> + *
> + *
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#include <soc/at91/atmel-sfr.h>
> +
> +#define I2S_BUS_NR 2
> +
> +struct clk_i2s_mux {
> + struct clk_hw hw;
> + struct regmap *regmap;
> + u32 bus_id;
Can be a u8?
> +};
> +
> +#define to_clk_i2s_mux(hw) container_of(hw, struct clk_i2s_mux, hw)
> +
> +static u8 clk_i2s_mux_get_parent(struct clk_hw *hw)
> +{
> + struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
> + u32 val;
> +
> + regmap_read(mux->regmap, AT91_SFR_I2SCLKSEL, &val);
> +
> + return (val & BIT(mux->bus_id)) >> mux->bus_id;
> +}
> +
> +static int clk_i2s_mux_set_parent(struct clk_hw *hw, u8 index)
> +{
> + struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
> +
> + return regmap_update_bits(mux->regmap, AT91_SFR_I2SCLKSEL,
> + BIT(mux->bus_id), index << mux->bus_id);
> +}
> +
> +const struct clk_ops clk_i2s_mux_ops = {
static?
> + .get_parent = clk_i2s_mux_get_parent,
> + .set_parent = clk_i2s_mux_set_parent,
> + .determine_rate = __clk_mux_determine_rate,
> +};
> +
> +static struct clk_hw * __init
> +at91_clk_i2s_mux_register(struct regmap *regmap, const char *name,
> + const char * const *parent_names,
> + unsigned int num_parents, u32 bus_id)
> +{
> + struct clk_init_data init = {};
> + struct clk_i2s_mux *i2s_ck;
> + int ret;
> +
> + i2s_ck = kzalloc(sizeof(*i2s_ck), GFP_KERNEL);
> + if (!i2s_ck)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = name;
> + init.ops = &clk_i2s_mux_ops;
> + init.parent_names = parent_names;
> + init.num_parents = num_parents;
> + init.flags = CLK_IGNORE_UNUSED;
Really? Why?
> +
> + i2s_ck->hw.init = &init;
> + i2s_ck->bus_id = bus_id;
> + i2s_ck->regmap = regmap;
> +
> + ret = clk_hw_register(NULL, &i2s_ck->hw);
> + if (ret) {
> + kfree(i2s_ck);
> + return ERR_PTR(ret);
> + }
> +
> + return &i2s_ck->hw;
> +}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox