* [PATCH] ARM: davinci: dm365-evm: Add Fixed regulators needed for tlv320aic3101
From: Peter Ujfalusi @ 2019-08-30 10:22 UTC (permalink / raw)
To: nsekhar, bgolaszewski; +Cc: linux-kernel, linux-arm-kernel
The codec driver needs correct regulators in order to probe.
Both VCC_3V3 and VCC_1V8 is always on fixed regulators on the board.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-davinci/board-dm365-evm.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 150a36f333df..2328b15ac067 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -30,6 +30,8 @@
#include <linux/spi/eeprom.h>
#include <linux/v4l2-dv-timings.h>
#include <linux/platform_data/ti-aemif.h>
+#include <linux/regulator/fixed.h>
+#include <linux/regulator/machine.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -245,6 +247,19 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
+/* Fixed regulator support */
+static struct regulator_consumer_supply fixed_supplies_3_3v[] = {
+ /* Baseboard 3.3V: 5V -> TPS767D301 -> 3.3V */
+ REGULATOR_SUPPLY("AVDD", "1-0018"),
+ REGULATOR_SUPPLY("DRVDD", "1-0018"),
+ REGULATOR_SUPPLY("IOVDD", "1-0018"),
+};
+
+static struct regulator_consumer_supply fixed_supplies_1_8v[] = {
+ /* Baseboard 1.8V: 5V -> TPS767D301 -> 1.8V */
+ REGULATOR_SUPPLY("DVDD", "1-0018"),
+};
+
static int dm365evm_keyscan_enable(struct device *dev)
{
return davinci_cfg_reg(DM365_KEYSCAN);
@@ -800,6 +815,11 @@ static __init void dm365_evm_init(void)
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
+ regulator_register_always_on(0, "fixed-dummy", fixed_supplies_1_8v,
+ ARRAY_SIZE(fixed_supplies_1_8v), 1800000);
+ regulator_register_always_on(1, "fixed-dummy", fixed_supplies_3_3v,
+ ARRAY_SIZE(fixed_supplies_3_3v), 3300000);
+
nvmem_add_cell_table(&davinci_nvmem_cell_table);
nvmem_add_cell_lookups(&davinci_nvmem_cell_lookup, 1);
--
Peter
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 related
* [PATCH] ARM: davinci: dm365: Fix McBSP dma_slave_map entry
From: Peter Ujfalusi @ 2019-08-30 10:22 UTC (permalink / raw)
To: nsekhar, bgolaszewski; +Cc: linux-kernel, linux-arm-kernel
dm365 have only single McBSP, so the device name is without .0
Fixes: 0c750e1fe481d ("ARM: davinci: dm365: Add dma_slave_map to edma")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-davinci/dm365.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 2f9ae6431bf5..cebab6af31a2 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -462,8 +462,8 @@ static s8 dm365_queue_priority_mapping[][2] = {
};
static const struct dma_slave_map dm365_edma_map[] = {
- { "davinci-mcbsp.0", "tx", EDMA_FILTER_PARAM(0, 2) },
- { "davinci-mcbsp.0", "rx", EDMA_FILTER_PARAM(0, 3) },
+ { "davinci-mcbsp", "tx", EDMA_FILTER_PARAM(0, 2) },
+ { "davinci-mcbsp", "rx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci_voicecodec", "tx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci_voicecodec", "rx", EDMA_FILTER_PARAM(0, 3) },
{ "spi_davinci.2", "tx", EDMA_FILTER_PARAM(0, 10) },
--
Peter
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 related
* Re: [PATCH v5 10/10] arm64: atomics: Use K constraint when toolchain appears to support it
From: Will Deacon @ 2019-08-30 10:17 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland, peterz, catalin.marinas, ndesaulniers,
Ard.Biesheuvel, natechancellor, robin.murphy, linux-arm-kernel
In-Reply-To: <20190830091155.GS14582@e119886-lin.cambridge.arm.com>
On Fri, Aug 30, 2019 at 10:11:55AM +0100, Andrew Murray wrote:
> On Fri, Aug 30, 2019 at 08:52:20AM +0100, Will Deacon wrote:
> > On Fri, Aug 30, 2019 at 01:08:03AM +0100, Andrew Murray wrote:
> > > On Thu, Aug 29, 2019 at 05:54:58PM +0100, Will Deacon wrote:
> > > > On Thu, Aug 29, 2019 at 04:48:34PM +0100, Will Deacon wrote:
> > > > > diff --git a/arch/arm64/include/asm/atomic_ll_sc.h b/arch/arm64/include/asm/atomic_ll_sc.h
> > > > > index 95091f72228b..7fa042f5444e 100644
> > > > > --- a/arch/arm64/include/asm/atomic_ll_sc.h
> > > > > +++ b/arch/arm64/include/asm/atomic_ll_sc.h
> > > > > @@ -23,6 +23,10 @@ asm_ops "\n" \
> > > > > #define __LL_SC_FALLBACK(asm_ops) asm_ops
> > > > > #endif
>
> I downloaded your original patches and tried them, and also got the
> build error. After playing with this I think something isn't quite right...
>
> This is your current test:
>
> echo 'int main(void) {asm volatile("and w0, w0, %w0" :: "K" (4294967295)); return 0; }' | aarch64-linux-gnu-gcc -S -x c - ; echo $?
>
> But on my machine this returns 0, i.e. no error. If I drop the -S:
>
> echo 'int main(void) {asm volatile("and w0, w0, %w0" :: "K" (4294967295)); return 0; }' | aarch64-linux-gnu-gcc -x c - ; echo $?
>
> Then this returns 1.
>
> So I guess the -S flag or something similar is needed.
This seems correct to me, and is the reason we pass -S in the Makefile. Why
are you dropping it?
In the first case, the (broken) compiler is emitted an assembly file
containing "and w0, w0, 4294967295", and so we will not define
CONFIG_CC_HAS_K_CONSTRAINT.
In the second case, you're passing the bad assembly file to GAS, which
rejects it.
> > > > > +#ifndef CONFIG_CC_HAS_K_CONSTRAINT
> > > > > +#define K
> > > > > +#endif
>
> Also, isn't this the wrong way around?
No. If the compiler doesn't support the K constraint, then we get:
[old] "" "r" (old)
because we've defined K as being nothing. Otherwise, we get:
[old] "K" "r" (old)
because K isn't defined as anything.
> It looks like when using $(call try-run,echo - it's the last argument that is
> used when the condition is false. Thus at present we seem to be setting
> CONFIG_CC_HAS_K_CONSTRAINT when 'K' is broken.
No. We set CONFIG_CC_HAS_K_CONSTRAINT when the compiler fails to generate
an assembly file with the invalid immediate.
> > Without the __stringify I get a compilation failure when building
> > kernel/panic.o because it tries to cmpxchg a 32-bit variable with -1
> > (PANIC_CPU_INVALID). Looking at panic.s, I see that constraint parameter
> > isn't being expanded. For example if I do:
> >
> > #ifndef CONFIG_CC_HAS_K_CONSTRAINT
> > #define INVALID_CONSTRAINT
> > #else
> > #define INVALID_CONSTRAINT K
> > #endif
> >
> > and then pass INVALID_CONSTRAINT to the generator macros, we'll end up
> > with INVALID_CONSTRAINT in the .s file and gas will barf.
>
> This still isn't an issue for me. Your patches cause the build to fail because
> it's using the K flag - if I invert the CONFIG_CC_HAS_K_CONSTRAINT test then
> it builds correctly (because it expands the K to nothing).
That doesn't make any sense :/ Is this after you've dropped the -S
parameter?
If you think there's a bug, please can you send a patch? However, inverting
the check breaks the build for me. Which toolchain are you using?
> If there is an issue with the expansion of constraint, shouldn't we also
> __stringify 'asm_op'?
It would be harmless, but there's no need because asm_op doesn't ever
require further expansion.
Will
_______________________________________________
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 v4 07/10] KVM: arm64: Provide VCPU attributes for stolen time
From: Marc Zyngier @ 2019-08-30 10:02 UTC (permalink / raw)
To: Steven Price, Will Deacon, linux-arm-kernel, kvmarm
Cc: Mark Rutland, kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Paolo Bonzini, Julien Thierry
In-Reply-To: <20190830084255.55113-8-steven.price@arm.com>
On 30/08/2019 09:42, Steven Price wrote:
> Allow user space to inform the KVM host where in the physical memory
> map the paravirtualized time structures should be located.
>
> User space can set an attribute on the VCPU providing the IPA base
> address of the stolen time structure for that VCPU. This must be
> repeated for every VCPU in the VM.
>
> The address is given in terms of the physical address visible to
> the guest and must be 64 byte aligned. The guest will discover the
> address via a hypercall.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 7 +++++
> arch/arm64/include/uapi/asm/kvm.h | 2 ++
> arch/arm64/kvm/guest.c | 9 ++++++
> include/uapi/linux/kvm.h | 2 ++
> virt/kvm/arm/pvtime.c | 47 +++++++++++++++++++++++++++++++
> 5 files changed, 67 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 1697e63f6dd8..6af16b29a41f 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -489,6 +489,13 @@ long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu);
> long kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu);
> int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init);
>
> +int kvm_arm_pvtime_set_attr(struct kvm_vcpu *vcpu,
> + struct kvm_device_attr *attr);
> +int kvm_arm_pvtime_get_attr(struct kvm_vcpu *vcpu,
> + struct kvm_device_attr *attr);
> +int kvm_arm_pvtime_has_attr(struct kvm_vcpu *vcpu,
> + struct kvm_device_attr *attr);
> +
> static inline void kvm_arm_pvtime_vcpu_init(struct kvm_vcpu_arch *vcpu_arch)
> {
> vcpu_arch->steal.base = GPA_INVALID;
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 9a507716ae2f..bde9f165ad3a 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -323,6 +323,8 @@ struct kvm_vcpu_events {
> #define KVM_ARM_VCPU_TIMER_CTRL 1
> #define KVM_ARM_VCPU_TIMER_IRQ_VTIMER 0
> #define KVM_ARM_VCPU_TIMER_IRQ_PTIMER 1
> +#define KVM_ARM_VCPU_PVTIME_CTRL 2
> +#define KVM_ARM_VCPU_PVTIME_SET_IPA 0
>
> /* KVM_IRQ_LINE irq field index values */
> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index dfd626447482..d3ac9d2fd405 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -858,6 +858,9 @@ int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
> case KVM_ARM_VCPU_TIMER_CTRL:
> ret = kvm_arm_timer_set_attr(vcpu, attr);
> break;
> + case KVM_ARM_VCPU_PVTIME_CTRL:
> + ret = kvm_arm_pvtime_set_attr(vcpu, attr);
> + break;
> default:
> ret = -ENXIO;
> break;
> @@ -878,6 +881,9 @@ int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
> case KVM_ARM_VCPU_TIMER_CTRL:
> ret = kvm_arm_timer_get_attr(vcpu, attr);
> break;
> + case KVM_ARM_VCPU_PVTIME_CTRL:
> + ret = kvm_arm_pvtime_get_attr(vcpu, attr);
> + break;
> default:
> ret = -ENXIO;
> break;
> @@ -898,6 +904,9 @@ int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
> case KVM_ARM_VCPU_TIMER_CTRL:
> ret = kvm_arm_timer_has_attr(vcpu, attr);
> break;
> + case KVM_ARM_VCPU_PVTIME_CTRL:
> + ret = kvm_arm_pvtime_has_attr(vcpu, attr);
> + break;
> default:
> ret = -ENXIO;
> break;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 5e3f12d5359e..265156a984f2 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1222,6 +1222,8 @@ enum kvm_device_type {
> #define KVM_DEV_TYPE_ARM_VGIC_ITS KVM_DEV_TYPE_ARM_VGIC_ITS
> KVM_DEV_TYPE_XIVE,
> #define KVM_DEV_TYPE_XIVE KVM_DEV_TYPE_XIVE
> + KVM_DEV_TYPE_ARM_PV_TIME,
> +#define KVM_DEV_TYPE_ARM_PV_TIME KVM_DEV_TYPE_ARM_PV_TIME
> KVM_DEV_TYPE_MAX,
> };
>
> diff --git a/virt/kvm/arm/pvtime.c b/virt/kvm/arm/pvtime.c
> index d9d0dbc6994b..7b1834b98a68 100644
> --- a/virt/kvm/arm/pvtime.c
> +++ b/virt/kvm/arm/pvtime.c
> @@ -2,7 +2,9 @@
> // Copyright (C) 2019 Arm Ltd.
>
> #include <linux/arm-smccc.h>
> +#include <linux/kvm_host.h>
>
> +#include <asm/kvm_mmu.h>
> #include <asm/pvclock-abi.h>
>
> #include <kvm/arm_hypercalls.h>
> @@ -75,3 +77,48 @@ long kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
>
> return vcpu->arch.steal.base;
> }
> +
> +int kvm_arm_pvtime_set_attr(struct kvm_vcpu *vcpu,
> + struct kvm_device_attr *attr)
> +{
> + u64 __user *user = (u64 __user *)attr->addr;
> + u64 ipa;
> +
> + if (attr->attr != KVM_ARM_VCPU_PVTIME_SET_IPA)
> + return -ENXIO;
> +
> + if (get_user(ipa, user))
> + return -EFAULT;
> + if (ipa & 63)
nit: Please express this as !IS_ALIGNED(ipa, 64) instead.
> + return -EINVAL;
> + if (vcpu->arch.steal.base != GPA_INVALID)
> + return -EEXIST;
> + vcpu->arch.steal.base = ipa;
I'm still worried that you end-up not knowing whether the IPA is valid
or not at this stage, nor that we check about overlapping vcpus. How do
we validate that?
I also share Christoffer's concern that the memslot parsing may be
expensive on a system with multiple memslots. But maybe that can be
solved by adding some caching capabilities to your kvm_put_guest(),
should this become a problem.
> + return 0;
> +}
> +
> +int kvm_arm_pvtime_get_attr(struct kvm_vcpu *vcpu,
> + struct kvm_device_attr *attr)
> +{
> + u64 __user *user = (u64 __user *)attr->addr;
> + u64 ipa;
> +
> + if (attr->attr != KVM_ARM_VCPU_PVTIME_SET_IPA)
It is a bit odd that this is using "SET_IPA" as a way to GET it.
> + return -ENXIO;
> +
> + ipa = vcpu->arch.steal.base;
> +
> + if (put_user(ipa, user))
> + return -EFAULT;
> + return 0;
> +}
> +
> +int kvm_arm_pvtime_has_attr(struct kvm_vcpu *vcpu,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->attr) {
> + case KVM_ARM_VCPU_PVTIME_SET_IPA:
> + return 0;
> + }
> + return -ENXIO;
> +}
>
Thanks,
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
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 2/8] videodev2.h: add V4L2_DEC_CMD_FLUSH
From: Alexandre Courbot @ 2019-08-30 9:48 UTC (permalink / raw)
To: Hans Verkuil
Cc: devel, Jernej Skrabec, Linux Media Mailing List, Pawel Osciak,
jonas, gregkh, Chen-Yu Tsai, mripard, Tomasz Figa,
Paul Kocialkowski, Kyungmin Park,
moderated list:ARM/Mediatek SoC support, Mauro Carvalho Chehab,
Ezequiel Garcia, LKML, Marek Szyprowski
In-Reply-To: <907f3c43-b994-f1c7-a15b-116566e19003@xs4all.nl>
On Fri, Aug 30, 2019 at 6:45 PM Hans Verkuil <hverkuil-cisco@xs4all.nl> wrote:
>
> On 8/30/19 11:38 AM, Alexandre Courbot wrote:
> > On Fri, Aug 23, 2019 at 4:45 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> >>
> >> From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> >>
> >> Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
> >>
> >> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> >> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> ---
> >> Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++++++++++-
> >> Documentation/media/videodev2.h.rst.exceptions | 1 +
> >> include/uapi/linux/videodev2.h | 1 +
> >> 3 files changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> >> index 57f0066f4cff..0bffef6058f7 100644
> >> --- a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> >> +++ b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> >> @@ -208,7 +208,16 @@ introduced in Linux 3.3. They are, however, mandatory for stateful mem2mem decod
> >> been started yet, the driver will return an ``EPERM`` error code. When
> >> the decoder is already running, this command does nothing. No
> >> flags are defined for this command.
> >> -
> >> + * - ``V4L2_DEC_CMD_FLUSH``
> >> + - 4
> >> + - Flush any held capture buffers. Only valid for stateless decoders,
> >> + and only if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` was set.
> >> + This command is typically used when the application reached the
> >> + end of the stream and the last output buffer had the
> >> + ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
> >> + dequeueing the last capture buffer containing the last decoded frame.
> >> + So this command can be used to explicitly flush that last decoded
> >> + frame.
> >
> > Just for safety, can we also specify that it is valid to call this
> > command even if no buffer was held (in which case it is a no-op), as
> > this can help make user-space code simpler?
>
> Ah yes, thanks for the reminder.
>
> Jernej, when you post the next version of this series, can you change the text
> above to:
>
> - Flush any held capture buffers. Only valid for stateless decoders.
> This command is typically used when the application reached the
> end of the stream and the last output buffer had the
> ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
> dequeueing the capture buffer containing the last decoded frame.
> So this command can be used to explicitly flush that final decoded
> frame. This command does nothing if there are no held capture buffers.
With the above,
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Thanks!
>
> Regards,
>
> Hans
>
> >
> >>
> >> Return Value
> >> ============
> >> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
> >> index adeb6b7a15cb..a79028e4d929 100644
> >> --- a/Documentation/media/videodev2.h.rst.exceptions
> >> +++ b/Documentation/media/videodev2.h.rst.exceptions
> >> @@ -434,6 +434,7 @@ replace define V4L2_DEC_CMD_START decoder-cmds
> >> replace define V4L2_DEC_CMD_STOP decoder-cmds
> >> replace define V4L2_DEC_CMD_PAUSE decoder-cmds
> >> replace define V4L2_DEC_CMD_RESUME decoder-cmds
> >> +replace define V4L2_DEC_CMD_FLUSH decoder-cmds
> >>
> >> replace define V4L2_DEC_CMD_START_MUTE_AUDIO decoder-cmds
> >> replace define V4L2_DEC_CMD_PAUSE_TO_BLACK decoder-cmds
> >> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> >> index 4fa9f543742d..91a79e16089c 100644
> >> --- a/include/uapi/linux/videodev2.h
> >> +++ b/include/uapi/linux/videodev2.h
> >> @@ -1978,6 +1978,7 @@ struct v4l2_encoder_cmd {
> >> #define V4L2_DEC_CMD_STOP (1)
> >> #define V4L2_DEC_CMD_PAUSE (2)
> >> #define V4L2_DEC_CMD_RESUME (3)
> >> +#define V4L2_DEC_CMD_FLUSH (4)
> >>
> >> /* Flags for V4L2_DEC_CMD_START */
> >> #define V4L2_DEC_CMD_START_MUTE_AUDIO (1 << 0)
> >> --
> >> 2.22.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 v4 05/10] KVM: arm64: Support stolen time reporting via shared structure
From: Steven Price @ 2019-08-30 9:52 UTC (permalink / raw)
To: Christoffer Dall
Cc: kvm, linux-doc, Marc Zyngier, Russell King, linux-kernel,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190830094245.GB5307@e113682-lin.lund.arm.com>
On 30/08/2019 10:42, Christoffer Dall wrote:
> On Fri, Aug 30, 2019 at 09:42:50AM +0100, Steven Price wrote:
>> Implement the service call for configuring a shared structure between a
>> VCPU and the hypervisor in which the hypervisor can write the time
>> stolen from the VCPU's execution time by other tasks on the host.
>>
>> The hypervisor allocates memory which is placed at an IPA chosen by user
>> space. The hypervisor then updates the shared structure using
>> kvm_put_guest() to ensure single copy atomicity of the 64-bit value
>> reporting the stolen time in nanoseconds.
>>
>> Whenever stolen time is enabled by the guest, the stolen time counter is
>> reset.
>>
>> The stolen time itself is retrieved from the sched_info structure
>> maintained by the Linux scheduler code. We enable SCHEDSTATS when
>> selecting KVM Kconfig to ensure this value is meaningful.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
[...]
>> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
>> +{
>> + struct kvm *kvm = vcpu->kvm;
>> + u64 steal;
>> + u64 steal_le;
>> + u64 offset;
>> + int idx;
>> + u64 base = vcpu->arch.steal.base;
>> +
>> + if (base == GPA_INVALID)
>> + return -ENOTSUPP;
>> +
>> + /* Let's do the local bookkeeping */
>> + steal = vcpu->arch.steal.steal;
>> + steal += current->sched_info.run_delay - vcpu->arch.steal.last_steal;
>> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
>> + vcpu->arch.steal.steal = steal;
>> +
>> + steal_le = cpu_to_le64(steal);
>> + idx = srcu_read_lock(&kvm->srcu);
>> + if (init) {
>> + struct pvclock_vcpu_stolen_time init_values = {
>> + .revision = 0,
>> + .attributes = 0
>> + };
>> + kvm_write_guest(kvm, base, &init_values,
>> + sizeof(init_values));
>> + }
>> + offset = offsetof(struct pvclock_vcpu_stolen_time, stolen_time);
>> + kvm_put_guest(kvm, base + offset, steal_le, u64);
>
> Let's hope we don't have thousands of memslots through which we have to
> do a linear scan on every vcpu load after this. If that were the case,
> I think the memslot search path would have to be updated anyhow.
Yes I'm not sure with the current memslot implementation it is actually
beneficial to split up the stolen time structures into separate
memslots. But there's nothing requiring the use of so many memslots.
If this is really a problem it would be possible to implement a
memslot-caching kvm_put_guest(), but I'd want to wait until someone
shows there's actually a problem first.
> Otherwise looks reasonable to me.
Great, thanks for the review.
Steve
_______________________________________________
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] arm64: numa: check the node id before accessing node_to_cpumask_map
From: Yunsheng Lin @ 2019-08-30 9:49 UTC (permalink / raw)
To: Michal Hocko
Cc: tglx, anshuman.khandual, robin.murphy, linuxarm, linux-kernel,
rppt, cai, akpm, will, adobriyan, linux-arm-kernel
In-Reply-To: <20190830083925.GV28313@dhcp22.suse.cz>
On 2019/8/30 16:39, Michal Hocko wrote:
> On Fri 30-08-19 16:08:14, Yunsheng Lin wrote:
>> On 2019/8/30 14:44, Michal Hocko wrote:
>>> On Fri 30-08-19 14:35:26, Yunsheng Lin wrote:
>>>> On 2019/8/30 13:55, Michal Hocko wrote:
>>>>> On Fri 30-08-19 10:26:31, Yunsheng Lin wrote:
>>>>>> Some buggy bios may not set the device' numa id, and dev_to_node
>>>>>> will return -1, which may cause global-out-of-bounds error
>>>>>> detected by KASAN.
>>>>>
>>>>> Why should we workaround a buggy bios like that? Is it so widespread and
>>>>> no BIOS update available? Also, why is this arm64 specific?
>>>>
>>>> For our case, there is BIOS update available. I just thought it might
>>>> be better to protect from this case when BIOS has not implemented the
>>>> device' numa id setting feature or the feature from BIOS has some bug.
>>>>
>>>> It is not arm64 specific, right now I only have arm64 board. If it is
>>>> ok to protect this from the buggy BIOS, maybe all other arch can be
>>>> changed too.
>>>
>>> If we are to really care then this should be consistent among
>>> architectures IMHO. But I am not really sure this is really worth it.
>>> The code is quite old and I do not really remember any reports.
>>
>> It is only detected by enabling KASAN, the system seems to run fine without
>> any visible error if KASAN is disabled. Maybe there is why no report has
>> been seen?
>>
>> Also according to Section 6.2.14 from ACPI spec 6.3 [1], the setting of proximity
>> domain is optional, as below:
>>
>> This optional object is used to describe proximity domain
>> associations within a machine. _PXM evaluates to an integer
>> that identifies a device as belonging to a Proximity Domain
>> defined in the System Resource Affinity Table (SRAT).
>>
>>
>> Do you think it is ok to resend the fix with above clarification and below
>> log:
>
> OK, if the specification really allows to provide NUMA_NO_NODE (-1) then
> the code really has to be prepared for that. And ideally all arches
> should deal with that.
>
>> [ 42.970381] ==================================================================
>> [ 42.977595] BUG: KASAN: global-out-of-bounds in __bitmap_weight+0x48/0xb0
>> [ 42.984370] Read of size 8 at addr ffff20008cdf8790 by task kworker/0:1/13
>> [ 42.991230]
>> [ 42.992712] CPU: 0 PID: 13 Comm: kworker/0:1 Tainted: G O 5.2.0-rc4-g8bde06a-dirty #3
>> [ 43.001830] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.B050.01 08/08/2019
>> [ 43.011298] Workqueue: events work_for_cpu_fn
>> [ 43.015643] Call trace:
>> [ 43.018078] dump_backtrace+0x0/0x1e8
>> [ 43.021727] show_stack+0x14/0x20
>> [ 43.025031] dump_stack+0xc4/0xfc
>> [ 43.028335] print_address_description+0x178/0x270
>> [ 43.033113] __kasan_report+0x164/0x1b8
>> [ 43.036936] kasan_report+0xc/0x18
>> [ 43.040325] __asan_load8+0x84/0xa8
>> [ 43.043801] __bitmap_weight+0x48/0xb0
>> [ 43.047552] hclge_init_ae_dev+0x988/0x1e78 [hclge]
>> [ 43.052418] hnae3_register_ae_dev+0xcc/0x278 [hnae3]
>> [ 43.057467] hns3_probe+0xe0/0x120 [hns3]
>> [ 43.061464] local_pci_probe+0x74/0xf0
>> [ 43.065200] work_for_cpu_fn+0x2c/0x48
>> [ 43.068937] process_one_work+0x3c0/0x878
>> [ 43.072934] worker_thread+0x400/0x670
>> [ 43.076670] kthread+0x1b0/0x1b8
>> [ 43.079885] ret_from_fork+0x10/0x18
>> [ 43.083446]
>> [ 43.084925] The buggy address belongs to the variable:
>> [ 43.090052] numa_distance+0x30/0x40
>> [ 43.093613]
>> [ 43.095091] Memory state around the buggy address:
>> [ 43.099870] ffff20008cdf8680: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 fa fa
>> [ 43.107078] ffff20008cdf8700: fa fa fa fa 04 fa fa fa fa fa fa fa 00 fa fa fa
>> [ 43.114286] >ffff20008cdf8780: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
>> [ 43.121494] ^
>> [ 43.125230] ffff20008cdf8800: 01 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
>> [ 43.132439] ffff20008cdf8880: fa fa fa fa fa fa fa fa 00 00 fa fa fa fa fa fa
>> [ 43.139646] ==================================================================
>>
>>
>>>
>>>>>> This patch changes cpumask_of_node to return cpu_none_mask if the
>>>>>> node is not valid, and sync the cpumask_of_node between the
>>>>>> cpumask_of_node function in numa.h and numa.c.
>>>>>
>>>>> Why?
>>>>
>>>> When CONFIG_DEBUG_PER_CPU_MAPS is defined, the cpumask_of_node() in
>>>> numa.c is used, if not, the cpumask_of_node() in numa.h is used.
>>>>
>>>> I am not sure why there is difference between them, and it is there
>>>> when since the below commit:
>>>> 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.")
>>>>
>>>> I synced them to keep them consistent whether CONFIG_DEBUG_PER_CPU_MAPS
>>>> is defined.
>>>
>>> Such a change should be made in a separate patch with a full
>>> clarification/justification. From the above it is still not clear why
>>> this is needed though.
>>
>> Ok.
>>
>> How about:
>>
>> Currently there are different implementations of cpumask_of_node() depend
>> on the arch, for example:
>>
>> ia64:
>> #define cpumask_of_node(node) ((node) == -1 ? \
>> cpu_all_mask : \
>> &node_to_cpu_mask[node])
>>
>>
>> alpha:
>> static const struct cpumask *cpumask_of_node(int node)
>> {
>> int cpu;
>>
>> if (node == NUMA_NO_NODE)
>> return cpu_all_mask;
>>
>> cpumask_clear(&node_to_cpumask_map[node]);
>>
>> for_each_online_cpu(cpu) {
>> if (cpu_to_node(cpu) == node)
>> cpumask_set_cpu(cpu, node_to_cpumask_map[node]);
>> }
>>
>> return &node_to_cpumask_map[node];
>> }
>>
>> Even for the same arch, there are two implementations depend on the
>> CONFIG_DEBUG_PER_CPU_MAPS configuration.
>>
>> arm64/x86 without CONFIG_DEBUG_PER_CPU_MAPS:
>> static inline const struct cpumask *cpumask_of_node(int node)
>> {
>> return node_to_cpumask_map[node];
>> }
>>
>> arm64/x86 with CONFIG_DEBUG_PER_CPU_MAPS:
>> const struct cpumask *cpumask_of_node(int node)
>> {
>> if (WARN_ON(node >= nr_node_ids))
>> return cpu_none_mask;
>>
>> if (WARN_ON(node_to_cpumask_map[node] == NULL))
>> return cpu_online_mask;
>>
>> return node_to_cpumask_map[node];
>> }
>>
>> It seems the cpumask_of_node with CONFIG_DEBUG_PER_CPU_MAPS is used
>> to catch the erorr case and give a warning to user when node id is not
>> valid.
>
> Yeah the config help text
> config DEBUG_PER_CPU_MAPS
> bool "Debug access to per_cpu maps"
> depends on DEBUG_KERNEL
> depends on SMP
> help
> Say Y to verify that the per_cpu map being accessed has
> been set up. This adds a fair amount of code to kernel memory
> and decreases performance.
>
> Say N if unsure.
>
> suggests that this is intentionally hidden behind a config so a normal
> path shouldn't really duplicate it. If those checks make sense in
> general then the config option should be dropped I think.
It seems cpumask_of_node with CONFIG_DEBUG_PER_CPU_MAPS on may be used to
debug some early use of cpumask_of_node problem, see below:
/*
* Allocate node_to_cpumask_map based on number of available nodes
* Requires node_possible_map to be valid.
*
* Note: cpumask_of_node() is not valid until after this is done.
* (Use CONFIG_DEBUG_PER_CPU_MAPS to check this.)
*/
static void __init setup_node_to_cpumask_map(void)
{
int node;
/* setup nr_node_ids if not done yet */
if (nr_node_ids == MAX_NUMNODES)
setup_nr_node_ids();
/* allocate and clear the mapping */
for (node = 0; node < nr_node_ids; node++) {
alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
cpumask_clear(node_to_cpumask_map[node]);
}
/* cpumask_of_node() will now work */
pr_debug("Node to cpumask map for %u nodes\n", nr_node_ids);
}
So I prefer to keep it as two implementations for arm64 and x86, but
ensure the two implementations be consistent. It can be cleaned up later
when there is no use at all.
Is it ok with you?
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv1 0/3] Odroid c2 missing regulator linking
From: Neil Armstrong @ 2019-08-30 9:50 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, Martin Blumenstingl, Kevin Hilman, Linux Kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <CANAwSgQwZg_AXAnAY4KwDzHpwcSA9up7SrR6jyv5Bem24wtaJg@mail.gmail.com>
On 30/08/2019 11:34, Anand Moon wrote:
> Hi Neil,
>
> On Fri, 30 Aug 2019 at 13:01, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> On 29/08/2019 20:35, Anand Moon wrote:
>>> Hi Neil,
>>>
>>> On Thu, 29 Aug 2019 at 13:58, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>>
>>>> On 28/08/2019 22:27, Anand Moon wrote:
>>>>> Below small changes help re-configure or fix missing inter linking
>>>>> of regulator node.
>>>>>
>>>>> Changes based top on my prevoius series.
>>>>
>>>> For the serie:
>>>> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>
>>>
>>> Thanks for your review.
>>>
>>>>>
>>>>> [0] https://patchwork.kernel.org/cover/11113091/
>>>>>
>>>>> TOOD: Add support for DVFS GXBB odroid board in next series.
>>>>
>>>> I'm curious how you will do this !
>>>
>>> I was just studying you previous series on how you have implemented
>>> this feature for C1, N2 and VIM3 boards.
>>>
>>> [0] https://patchwork.kernel.org/cover/11114125/
>>>
>>> I started gathering key inputs needed for this ie *clk / pwm*
>>> like VDDCPU and VDDE clk changes.
>>>
>>> But it looks like of the complex clk framework needed, so I leave this to the
>>> expert like your team of developers to do this much quick and efficiently.
>>
>> On GXBB, GXL, GXM and AXG SoCs, CPU Frequency setting and PWM Regulator setup is
>> done by the SCPI Co-processor via the SCPI protocol.
>>
>> Thus, we should not handle it from Linux, and even if we could, we don't have the
>> registers documentation of the CPU clusters clock tree.
>>
>
> Ok thanks.
>
>> SCPI works fine on all tested devices, except Odroid-C2, because Hardkernel left
>> the > 1.5GHz freq in the initial SCPI tables loaded by the BL2, i.e. packed with U-Boot.
>> Nowadays they have removed the bad frequencies, but still some devices uses the old
>> bootloader.
>>
>> But in the SCPI case we trust the table returned by the firmware and use it as-in,
>> and there is no (simple ?) way to override the table and set a max frequency.
>>
>> This is why we disabled SCPI.
>>
>> See https://patchwork.kernel.org/patch/9500175/
>
> I have quickly enable this on my board and here the cpufreq info
>
> [alarm@alarm ~]$ cpupower frequency-info
> analyzing CPU 0:
> driver: scpi-cpufreq
> CPUs which run at the same hardware frequency: 0 1 2 3
> CPUs which need to have their frequency coordinated by software: 0 1 2 3
> maximum transition latency: 200 us
> hardware limits: 100.0 MHz - 1.54 GHz
> available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 1000 MHz,
> 1.30 GHz, 1.54 GHz
> available cpufreq governors: conservative ondemand userspace
> powersave performance schedutil
> current policy: frequency should be within 100.0 MHz and 1.54 GHz.
> The governor "ondemand" may decide which speed to use
> within this range.
> current CPU frequency: Unable to call hardware
> current CPU frequency: 250 MHz (asserted by call to kernel)
>
> I did some simple stress testing and observed the freq scaling is
> working fine when cpufreq governor is set to ondemand.
>
> Powertop output.
> Package | CPU 0
> 100 MHz 5.2% | 100 MHz 1.6%
> 250 MHz 4.4% | 250 MHz 4.3%
> 500 MHz 2.6% | 500 MHz 2.4%
> 1000 MHz 0.5% | 1000 MHz 0.3%
> 1296 MHz 0.2% | 1296 MHz 0.1%
> 1.54 GHz 0.2% | 1.54 GHz 0.1%
> Idle 86.9% | Idle 91.2%
>
> Here the output on the linaro's pm-qa testing for cpufreq.
>
> [1] https://pastebin.com/h880WATn
> Almost all the test case pass with this one as off now.
Thanks for passing the tests, no doubt it works with a recent
bootloader binary, but we can't leave alone the first Odroid-C2
devices loaded with an incorrect SCPI table.
I'll let Kevin decide for the following.
Neil
>
> Best Regards
> -Anand
>
_______________________________________________
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 2/8] videodev2.h: add V4L2_DEC_CMD_FLUSH
From: Hans Verkuil @ 2019-08-30 9:44 UTC (permalink / raw)
To: Alexandre Courbot, Jernej Skrabec
Cc: devel, Linux Media Mailing List, Pawel Osciak, jonas, gregkh,
Chen-Yu Tsai, mripard, Tomasz Figa, Paul Kocialkowski,
Kyungmin Park, moderated list:ARM/Mediatek SoC support,
Mauro Carvalho Chehab, Ezequiel Garcia, LKML, Marek Szyprowski
In-Reply-To: <CAPBb6MUChtZcNSTa2uT50k6uPU9T68wofLYGUFRJntDhjH8+iw@mail.gmail.com>
On 8/30/19 11:38 AM, Alexandre Courbot wrote:
> On Fri, Aug 23, 2019 at 4:45 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
>>
>> From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
>>
>> Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
>>
>> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> ---
>> Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++++++++++-
>> Documentation/media/videodev2.h.rst.exceptions | 1 +
>> include/uapi/linux/videodev2.h | 1 +
>> 3 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
>> index 57f0066f4cff..0bffef6058f7 100644
>> --- a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
>> +++ b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
>> @@ -208,7 +208,16 @@ introduced in Linux 3.3. They are, however, mandatory for stateful mem2mem decod
>> been started yet, the driver will return an ``EPERM`` error code. When
>> the decoder is already running, this command does nothing. No
>> flags are defined for this command.
>> -
>> + * - ``V4L2_DEC_CMD_FLUSH``
>> + - 4
>> + - Flush any held capture buffers. Only valid for stateless decoders,
>> + and only if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` was set.
>> + This command is typically used when the application reached the
>> + end of the stream and the last output buffer had the
>> + ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
>> + dequeueing the last capture buffer containing the last decoded frame.
>> + So this command can be used to explicitly flush that last decoded
>> + frame.
>
> Just for safety, can we also specify that it is valid to call this
> command even if no buffer was held (in which case it is a no-op), as
> this can help make user-space code simpler?
Ah yes, thanks for the reminder.
Jernej, when you post the next version of this series, can you change the text
above to:
- Flush any held capture buffers. Only valid for stateless decoders.
This command is typically used when the application reached the
end of the stream and the last output buffer had the
``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
dequeueing the capture buffer containing the last decoded frame.
So this command can be used to explicitly flush that final decoded
frame. This command does nothing if there are no held capture buffers.
Regards,
Hans
>
>>
>> Return Value
>> ============
>> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
>> index adeb6b7a15cb..a79028e4d929 100644
>> --- a/Documentation/media/videodev2.h.rst.exceptions
>> +++ b/Documentation/media/videodev2.h.rst.exceptions
>> @@ -434,6 +434,7 @@ replace define V4L2_DEC_CMD_START decoder-cmds
>> replace define V4L2_DEC_CMD_STOP decoder-cmds
>> replace define V4L2_DEC_CMD_PAUSE decoder-cmds
>> replace define V4L2_DEC_CMD_RESUME decoder-cmds
>> +replace define V4L2_DEC_CMD_FLUSH decoder-cmds
>>
>> replace define V4L2_DEC_CMD_START_MUTE_AUDIO decoder-cmds
>> replace define V4L2_DEC_CMD_PAUSE_TO_BLACK decoder-cmds
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 4fa9f543742d..91a79e16089c 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -1978,6 +1978,7 @@ struct v4l2_encoder_cmd {
>> #define V4L2_DEC_CMD_STOP (1)
>> #define V4L2_DEC_CMD_PAUSE (2)
>> #define V4L2_DEC_CMD_RESUME (3)
>> +#define V4L2_DEC_CMD_FLUSH (4)
>>
>> /* Flags for V4L2_DEC_CMD_START */
>> #define V4L2_DEC_CMD_START_MUTE_AUDIO (1 << 0)
>> --
>> 2.22.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 ARM64 v4.4 V3 44/44] arm64: futex: Mask __user pointers prior to dereference
From: Mark Rutland @ 2019-08-30 9:42 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <965d727955b4a45ac1f12e67c6a433110ef94871.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:04:29PM +0530, Viresh Kumar wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> commit 91b2d3442f6a44dce875670d702af22737ad5eff upstream.
>
> The arm64 futex code has some explicit dereferencing of user pointers
> where performing atomic operations in response to a futex command. This
> patch uses masking to limit any speculative futex operations to within
> the user address space.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
This would have made more sense immediately following patch 11, as in
mainline and the v4.9 backport. Having things applied in the same order
makes it much easier to compare and verify.
Regardless:
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/futex.h | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
> index 34d4d2e2f561..8ab6e83cb629 100644
> --- a/arch/arm64/include/asm/futex.h
> +++ b/arch/arm64/include/asm/futex.h
> @@ -53,9 +53,10 @@
> : "memory")
>
> static inline int
> -arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
> +arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *_uaddr)
> {
> int oldval = 0, ret, tmp;
> + u32 __user *uaddr = __uaccess_mask_ptr(_uaddr);
>
> pagefault_disable();
>
> @@ -93,15 +94,17 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
> }
>
> static inline int
> -futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
> +futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *_uaddr,
> u32 oldval, u32 newval)
> {
> int ret = 0;
> u32 val, tmp;
> + u32 __user *uaddr;
>
> - if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
> + if (!access_ok(VERIFY_WRITE, _uaddr, sizeof(u32)))
> return -EFAULT;
>
> + uaddr = __uaccess_mask_ptr(_uaddr);
> asm volatile("// futex_atomic_cmpxchg_inatomic\n"
> ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_HAS_PAN, CONFIG_ARM64_PAN)
> " prfm pstl1strm, %2\n"
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 v4 05/10] KVM: arm64: Support stolen time reporting via shared structure
From: Christoffer Dall @ 2019-08-30 9:42 UTC (permalink / raw)
To: Steven Price
Cc: kvm, linux-doc, Marc Zyngier, linux-kernel, Russell King,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190830084255.55113-6-steven.price@arm.com>
On Fri, Aug 30, 2019 at 09:42:50AM +0100, Steven Price wrote:
> Implement the service call for configuring a shared structure between a
> VCPU and the hypervisor in which the hypervisor can write the time
> stolen from the VCPU's execution time by other tasks on the host.
>
> The hypervisor allocates memory which is placed at an IPA chosen by user
> space. The hypervisor then updates the shared structure using
> kvm_put_guest() to ensure single copy atomicity of the 64-bit value
> reporting the stolen time in nanoseconds.
>
> Whenever stolen time is enabled by the guest, the stolen time counter is
> reset.
>
> The stolen time itself is retrieved from the sched_info structure
> maintained by the Linux scheduler code. We enable SCHEDSTATS when
> selecting KVM Kconfig to ensure this value is meaningful.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm/include/asm/kvm_host.h | 20 +++++++++++
> arch/arm64/include/asm/kvm_host.h | 21 +++++++++++-
> arch/arm64/kvm/Kconfig | 1 +
> include/linux/kvm_types.h | 2 ++
> virt/kvm/arm/arm.c | 11 ++++++
> virt/kvm/arm/hypercalls.c | 3 ++
> virt/kvm/arm/pvtime.c | 56 +++++++++++++++++++++++++++++++
> 7 files changed, 113 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 5a0c3569ebde..5c401482d62d 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -39,6 +39,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -329,6 +330,25 @@ static inline long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> return SMCCC_RET_NOT_SUPPORTED;
> }
>
> +static inline long kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + return SMCCC_RET_NOT_SUPPORTED;
> +}
> +
> +static inline int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static inline void kvm_arm_pvtime_vcpu_init(struct kvm_vcpu_arch *vcpu_arch)
> +{
> +}
> +
> +static inline bool kvm_arm_is_pvtime_enabled(struct kvm_vcpu_arch *vcpu_arch)
> +{
> + return false;
> +}
> +
> void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
>
> struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 93b46d9526d0..1697e63f6dd8 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -44,6 +44,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -338,8 +339,14 @@ struct kvm_vcpu_arch {
> /* True when deferrable sysregs are loaded on the physical CPU,
> * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
> bool sysregs_loaded_on_cpu;
> -};
>
> + /* Guest PV state */
> + struct {
> + u64 steal;
> + u64 last_steal;
> + gpa_t base;
> + } steal;
> +};
> /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
> #define vcpu_sve_pffr(vcpu) ((void *)((char *)((vcpu)->arch.sve_state) + \
> sve_ffr_offset((vcpu)->arch.sve_max_vl)))
> @@ -479,6 +486,18 @@ int kvm_perf_init(void);
> int kvm_perf_teardown(void);
>
> long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu);
> +long kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu);
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init);
> +
> +static inline void kvm_arm_pvtime_vcpu_init(struct kvm_vcpu_arch *vcpu_arch)
> +{
> + vcpu_arch->steal.base = GPA_INVALID;
> +}
> +
> +static inline bool kvm_arm_is_pvtime_enabled(struct kvm_vcpu_arch *vcpu_arch)
> +{
> + return (vcpu_arch->steal.base != GPA_INVALID);
> +}
>
> void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
>
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index a67121d419a2..d8b88e40d223 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -39,6 +39,7 @@ config KVM
> select IRQ_BYPASS_MANAGER
> select HAVE_KVM_IRQ_BYPASS
> select HAVE_KVM_VCPU_RUN_PID_CHANGE
> + select SCHEDSTATS
> ---help---
> Support hosting virtualized guest machines.
> We don't support KVM with 16K page tables yet, due to the multiple
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index bde5374ae021..1c88e69db3d9 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@ -35,6 +35,8 @@ typedef unsigned long gva_t;
> typedef u64 gpa_t;
> typedef u64 gfn_t;
>
> +#define GPA_INVALID (~(gpa_t)0)
> +
> typedef unsigned long hva_t;
> typedef u64 hpa_t;
> typedef u64 hfn_t;
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 35a069815baf..eaceb2d0f0c0 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -40,6 +40,10 @@
> #include <asm/kvm_coproc.h>
> #include <asm/sections.h>
>
> +#include <kvm/arm_hypercalls.h>
> +#include <kvm/arm_pmu.h>
> +#include <kvm/arm_psci.h>
> +
> #ifdef REQUIRES_VIRT
> __asm__(".arch_extension virt");
> #endif
> @@ -350,6 +354,8 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
>
> kvm_arm_reset_debug_ptr(vcpu);
>
> + kvm_arm_pvtime_vcpu_init(&vcpu->arch);
> +
> return kvm_vgic_vcpu_init(vcpu);
> }
>
> @@ -379,6 +385,8 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> kvm_vcpu_load_sysregs(vcpu);
> kvm_arch_vcpu_load_fp(vcpu);
> kvm_vcpu_pmu_restore_guest(vcpu);
> + if (kvm_arm_is_pvtime_enabled(&vcpu->arch))
> + kvm_make_request(KVM_REQ_RECORD_STEAL, vcpu);
>
> if (single_task_running())
> vcpu_clear_wfe_traps(vcpu);
> @@ -644,6 +652,9 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu)
> * that a VCPU sees new virtual interrupts.
> */
> kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu);
> +
> + if (kvm_check_request(KVM_REQ_RECORD_STEAL, vcpu))
> + kvm_update_stolen_time(vcpu, false);
> }
> }
>
> diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c
> index e2521e0d3978..3091a5d2e842 100644
> --- a/virt/kvm/arm/hypercalls.c
> +++ b/virt/kvm/arm/hypercalls.c
> @@ -56,6 +56,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> case ARM_SMCCC_HV_PV_FEATURES:
> val = kvm_hypercall_pv_features(vcpu);
> break;
> + case ARM_SMCCC_HV_PV_TIME_ST:
> + val = kvm_hypercall_stolen_time(vcpu);
> + break;
> default:
> return kvm_psci_call(vcpu);
> }
> diff --git a/virt/kvm/arm/pvtime.c b/virt/kvm/arm/pvtime.c
> index 7887a61651c6..d9d0dbc6994b 100644
> --- a/virt/kvm/arm/pvtime.c
> +++ b/virt/kvm/arm/pvtime.c
> @@ -3,8 +3,45 @@
>
> #include <linux/arm-smccc.h>
>
> +#include <asm/pvclock-abi.h>
> +
> #include <kvm/arm_hypercalls.h>
>
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + u64 steal;
> + u64 steal_le;
> + u64 offset;
> + int idx;
> + u64 base = vcpu->arch.steal.base;
> +
> + if (base == GPA_INVALID)
> + return -ENOTSUPP;
> +
> + /* Let's do the local bookkeeping */
> + steal = vcpu->arch.steal.steal;
> + steal += current->sched_info.run_delay - vcpu->arch.steal.last_steal;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> + vcpu->arch.steal.steal = steal;
> +
> + steal_le = cpu_to_le64(steal);
> + idx = srcu_read_lock(&kvm->srcu);
> + if (init) {
> + struct pvclock_vcpu_stolen_time init_values = {
> + .revision = 0,
> + .attributes = 0
> + };
> + kvm_write_guest(kvm, base, &init_values,
> + sizeof(init_values));
> + }
> + offset = offsetof(struct pvclock_vcpu_stolen_time, stolen_time);
> + kvm_put_guest(kvm, base + offset, steal_le, u64);
Let's hope we don't have thousands of memslots through which we have to
do a linear scan on every vcpu load after this. If that were the case,
I think the memslot search path would have to be updated anyhow.
Otherwise looks reasonable to me.
Thanks,
Christoffer
> + srcu_read_unlock(&kvm->srcu, idx);
> +
> + return 0;
> +}
> +
> long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> {
> u32 feature = smccc_get_arg1(vcpu);
> @@ -12,6 +49,7 @@ long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
>
> switch (feature) {
> case ARM_SMCCC_HV_PV_FEATURES:
> + case ARM_SMCCC_HV_PV_TIME_ST:
> val = SMCCC_RET_SUCCESS;
> break;
> }
> @@ -19,3 +57,21 @@ long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> return val;
> }
>
> +long kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + int err;
> +
> + /*
> + * Start counting stolen time from the time the guest requests
> + * the feature enabled.
> + */
> + vcpu->arch.steal.steal = 0;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> +
> + err = kvm_update_stolen_time(vcpu, true);
> +
> + if (err)
> + return SMCCC_RET_NOT_SUPPORTED;
> +
> + return vcpu->arch.steal.base;
> +}
> --
> 2.20.1
>
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
_______________________________________________
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 ARM64 v4.4 V3 11/44] arm64: uaccess: Mask __user pointers for __arch_{clear, copy_*}_user
From: Mark Rutland @ 2019-08-30 9:41 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <821430ff13f625eca9e0a9700ddc161cbc7965ff.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:56PM +0530, Viresh Kumar wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> commit f71c2ffcb20dd8626880747557014bb9a61eb90e upstream.
>
> Like we've done for get_user and put_user, ensure that user pointers
> are masked before invoking the underlying __arch_{clear,copy_*}_user
> operations.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> [ v4.4: fixup for v4.4 style uaccess primitives ]
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/uaccess.h | 18 ++++++++++--------
> arch/arm64/kernel/arm64ksyms.c | 4 ++--
> arch/arm64/lib/clear_user.S | 6 +++---
> arch/arm64/lib/copy_in_user.S | 4 ++--
> 4 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index 693a0d784534..f2f5a152f372 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -303,19 +303,18 @@ do { \
>
> extern unsigned long __must_check __arch_copy_from_user(void *to, const void __user *from, unsigned long n);
> extern unsigned long __must_check __arch_copy_to_user(void __user *to, const void *from, unsigned long n);
> -extern unsigned long __must_check __copy_in_user(void __user *to, const void __user *from, unsigned long n);
> -extern unsigned long __must_check __clear_user(void __user *addr, unsigned long n);
> +extern unsigned long __must_check __arch_copy_in_user(void __user *to, const void __user *from, unsigned long n);
>
> static inline unsigned long __must_check __copy_from_user(void *to, const void __user *from, unsigned long n)
> {
> kasan_check_write(to, n);
> - return __arch_copy_from_user(to, from, n);
> + return __arch_copy_from_user(to, __uaccess_mask_ptr(from), n);
> }
>
> static inline unsigned long __must_check __copy_to_user(void __user *to, const void *from, unsigned long n)
> {
> kasan_check_read(from, n);
> - return __arch_copy_to_user(to, from, n);
> + return __arch_copy_to_user(__uaccess_mask_ptr(to), from, n);
> }
>
> static inline unsigned long __must_check copy_from_user(void *to, const void __user *from, unsigned long n)
> @@ -338,22 +337,25 @@ static inline unsigned long __must_check copy_to_user(void __user *to, const voi
> return n;
> }
>
> -static inline unsigned long __must_check copy_in_user(void __user *to, const void __user *from, unsigned long n)
> +static inline unsigned long __must_check __copy_in_user(void __user *to, const void __user *from, unsigned long n)
> {
> if (access_ok(VERIFY_READ, from, n) && access_ok(VERIFY_WRITE, to, n))
> - n = __copy_in_user(to, from, n);
> + n = __arch_copy_in_user(__uaccess_mask_ptr(to), __uaccess_mask_ptr(from), n);
> return n;
> }
> +#define copy_in_user __copy_in_user
>
> #define __copy_to_user_inatomic __copy_to_user
> #define __copy_from_user_inatomic __copy_from_user
>
> -static inline unsigned long __must_check clear_user(void __user *to, unsigned long n)
> +extern unsigned long __must_check __arch_clear_user(void __user *to, unsigned long n);
> +static inline unsigned long __must_check __clear_user(void __user *to, unsigned long n)
> {
> if (access_ok(VERIFY_WRITE, to, n))
> - n = __clear_user(__uaccess_mask_ptr(to), n);
> + n = __arch_clear_user(__uaccess_mask_ptr(to), n);
> return n;
> }
> +#define clear_user __clear_user
>
> extern long strncpy_from_user(char *dest, const char __user *src, long count);
>
> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
> index c654df05b7d7..abe4e0984dbb 100644
> --- a/arch/arm64/kernel/arm64ksyms.c
> +++ b/arch/arm64/kernel/arm64ksyms.c
> @@ -35,8 +35,8 @@ EXPORT_SYMBOL(clear_page);
> /* user mem (segment) */
> EXPORT_SYMBOL(__arch_copy_from_user);
> EXPORT_SYMBOL(__arch_copy_to_user);
> -EXPORT_SYMBOL(__clear_user);
> -EXPORT_SYMBOL(__copy_in_user);
> +EXPORT_SYMBOL(__arch_clear_user);
> +EXPORT_SYMBOL(__arch_copy_in_user);
>
> /* physical memory */
> EXPORT_SYMBOL(memstart_addr);
> diff --git a/arch/arm64/lib/clear_user.S b/arch/arm64/lib/clear_user.S
> index a9723c71c52b..fc6bb0f83511 100644
> --- a/arch/arm64/lib/clear_user.S
> +++ b/arch/arm64/lib/clear_user.S
> @@ -24,7 +24,7 @@
>
> .text
>
> -/* Prototype: int __clear_user(void *addr, size_t sz)
> +/* Prototype: int __arch_clear_user(void *addr, size_t sz)
> * Purpose : clear some user memory
> * Params : addr - user memory address to clear
> * : sz - number of bytes to clear
> @@ -32,7 +32,7 @@
> *
> * Alignment fixed up by hardware.
> */
> -ENTRY(__clear_user)
> +ENTRY(__arch_clear_user)
> ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
> mov x2, x1 // save the size for fixup return
> @@ -57,7 +57,7 @@ USER(9f, strb wzr, [x0] )
> ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
> ret
> -ENDPROC(__clear_user)
> +ENDPROC(__arch_clear_user)
>
> .section .fixup,"ax"
> .align 2
> diff --git a/arch/arm64/lib/copy_in_user.S b/arch/arm64/lib/copy_in_user.S
> index 81c8fc93c100..0219aa85b3cc 100644
> --- a/arch/arm64/lib/copy_in_user.S
> +++ b/arch/arm64/lib/copy_in_user.S
> @@ -67,7 +67,7 @@
> .endm
>
> end .req x5
> -ENTRY(__copy_in_user)
> +ENTRY(__arch_copy_in_user)
> ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
> add end, x0, x2
> @@ -76,7 +76,7 @@ ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
> mov x0, #0
> ret
> -ENDPROC(__copy_in_user)
> +ENDPROC(__arch_copy_in_user)
>
> .section .fixup,"ax"
> .align 2
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 ARM64 v4.4 V3 10/44] arm64: kasan: instrument user memory access API
From: Mark Rutland @ 2019-08-30 9:41 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <0e906aabc5057c5e23f1092747eaa842d20dd8b3.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:55PM +0530, Viresh Kumar wrote:
> From: Yang Shi <yang.shi@linaro.org>
>
> commit bffe1baff5d57521b0c41b6997c41ff1993e9818 upstream.
>
> The upstream commit 1771c6e1a567ea0ba2cccc0a4ffe68a1419fd8ef
> ("x86/kasan: instrument user memory access API") added KASAN instrument to
> x86 user memory access API, so added such instrument to ARM64 too.
>
> Define __copy_to/from_user in C in order to add kasan_check_read/write call,
> rename assembly implementation to __arch_copy_to/from_user.
>
> Tested by test_kasan module.
>
> Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Yang Shi <yang.shi@linaro.org>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/uaccess.h | 25 +++++++++++++++++++++----
> arch/arm64/kernel/arm64ksyms.c | 4 ++--
> arch/arm64/lib/copy_from_user.S | 4 ++--
> arch/arm64/lib/copy_to_user.S | 4 ++--
> 4 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index a34324436ce1..693a0d784534 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -22,6 +22,7 @@
> * User space memory access functions
> */
> #include <linux/bitops.h>
> +#include <linux/kasan-checks.h>
> #include <linux/string.h>
> #include <linux/thread_info.h>
>
> @@ -300,15 +301,29 @@ do { \
>
> #define put_user __put_user
>
> -extern unsigned long __must_check __copy_from_user(void *to, const void __user *from, unsigned long n);
> -extern unsigned long __must_check __copy_to_user(void __user *to, const void *from, unsigned long n);
> +extern unsigned long __must_check __arch_copy_from_user(void *to, const void __user *from, unsigned long n);
> +extern unsigned long __must_check __arch_copy_to_user(void __user *to, const void *from, unsigned long n);
> extern unsigned long __must_check __copy_in_user(void __user *to, const void __user *from, unsigned long n);
> extern unsigned long __must_check __clear_user(void __user *addr, unsigned long n);
>
> +static inline unsigned long __must_check __copy_from_user(void *to, const void __user *from, unsigned long n)
> +{
> + kasan_check_write(to, n);
> + return __arch_copy_from_user(to, from, n);
> +}
> +
> +static inline unsigned long __must_check __copy_to_user(void __user *to, const void *from, unsigned long n)
> +{
> + kasan_check_read(from, n);
> + return __arch_copy_to_user(to, from, n);
> +}
> +
> static inline unsigned long __must_check copy_from_user(void *to, const void __user *from, unsigned long n)
> {
> + kasan_check_write(to, n);
> +
> if (access_ok(VERIFY_READ, from, n))
> - n = __copy_from_user(to, from, n);
> + n = __arch_copy_from_user(to, from, n);
> else /* security hole - plug it */
> memset(to, 0, n);
> return n;
> @@ -316,8 +331,10 @@ static inline unsigned long __must_check copy_from_user(void *to, const void __u
>
> static inline unsigned long __must_check copy_to_user(void __user *to, const void *from, unsigned long n)
> {
> + kasan_check_read(from, n);
> +
> if (access_ok(VERIFY_WRITE, to, n))
> - n = __copy_to_user(to, from, n);
> + n = __arch_copy_to_user(to, from, n);
> return n;
> }
>
> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
> index 3b6d8cc9dfe0..c654df05b7d7 100644
> --- a/arch/arm64/kernel/arm64ksyms.c
> +++ b/arch/arm64/kernel/arm64ksyms.c
> @@ -33,8 +33,8 @@ EXPORT_SYMBOL(copy_page);
> EXPORT_SYMBOL(clear_page);
>
> /* user mem (segment) */
> -EXPORT_SYMBOL(__copy_from_user);
> -EXPORT_SYMBOL(__copy_to_user);
> +EXPORT_SYMBOL(__arch_copy_from_user);
> +EXPORT_SYMBOL(__arch_copy_to_user);
> EXPORT_SYMBOL(__clear_user);
> EXPORT_SYMBOL(__copy_in_user);
>
> diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
> index 4699cd74f87e..281e75db899a 100644
> --- a/arch/arm64/lib/copy_from_user.S
> +++ b/arch/arm64/lib/copy_from_user.S
> @@ -66,7 +66,7 @@
> .endm
>
> end .req x5
> -ENTRY(__copy_from_user)
> +ENTRY(__arch_copy_from_user)
> ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
> add end, x0, x2
> @@ -75,7 +75,7 @@ ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
> mov x0, #0 // Nothing to copy
> ret
> -ENDPROC(__copy_from_user)
> +ENDPROC(__arch_copy_from_user)
>
> .section .fixup,"ax"
> .align 2
> diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
> index 7512bbbc07ac..db4d187de61f 100644
> --- a/arch/arm64/lib/copy_to_user.S
> +++ b/arch/arm64/lib/copy_to_user.S
> @@ -65,7 +65,7 @@
> .endm
>
> end .req x5
> -ENTRY(__copy_to_user)
> +ENTRY(__arch_copy_to_user)
> ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
> add end, x0, x2
> @@ -74,7 +74,7 @@ ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
> CONFIG_ARM64_PAN)
> mov x0, #0
> ret
> -ENDPROC(__copy_to_user)
> +ENDPROC(__arch_copy_to_user)
>
> .section .fixup,"ax"
> .align 2
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 ARM64 v4.4 V3 09/44] mm/kasan: add API to check memory regions
From: Mark Rutland @ 2019-08-30 9:41 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <ea16af1feddcaa85dc5369c79f78c00256c698cd.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:54PM +0530, Viresh Kumar wrote:
> From: Andrey Ryabinin <aryabinin@virtuozzo.com>
>
> commit 64f8ebaf115bcddc4aaa902f981c57ba6506bc42 upstream.
>
> Memory access coded in an assembly won't be seen by KASAN as a compiler
> can instrument only C code. Add kasan_check_[read,write]() API which is
> going to be used to check a certain memory range.
>
> Link: http://lkml.kernel.org/r/1462538722-1574-3-git-send-email-aryabinin@virtuozzo.com
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Acked-by: Alexander Potapenko <glider@google.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> [ v4.4: Fixed MAINTAINERS conflict and added whole kasan entry. Drop 4th
> argument to check_memory_region(). ]
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> MAINTAINERS | 14 ++++++++++++++
> include/linux/kasan-checks.h | 12 ++++++++++++
> mm/kasan/kasan.c | 12 ++++++++++++
> 3 files changed, 38 insertions(+)
> create mode 100644 include/linux/kasan-checks.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f4d4a5544dc1..2a8826732967 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5982,6 +5982,20 @@ S: Maintained
> F: Documentation/hwmon/k8temp
> F: drivers/hwmon/k8temp.c
>
> +KASAN
> +M: Andrey Ryabinin <aryabinin@virtuozzo.com>
> +R: Alexander Potapenko <glider@google.com>
> +R: Dmitry Vyukov <dvyukov@google.com>
> +L: kasan-dev@googlegroups.com
> +S: Maintained
> +F: arch/*/include/asm/kasan.h
> +F: arch/*/mm/kasan_init*
> +F: Documentation/kasan.txt
> +F: include/linux/kasan*.h
> +F: lib/test_kasan.c
> +F: mm/kasan/
> +F: scripts/Makefile.kasan
> +
> KCONFIG
> M: "Yann E. MORIN" <yann.morin.1998@free.fr>
> L: linux-kbuild@vger.kernel.org
> diff --git a/include/linux/kasan-checks.h b/include/linux/kasan-checks.h
> new file mode 100644
> index 000000000000..b7f8aced7870
> --- /dev/null
> +++ b/include/linux/kasan-checks.h
> @@ -0,0 +1,12 @@
> +#ifndef _LINUX_KASAN_CHECKS_H
> +#define _LINUX_KASAN_CHECKS_H
> +
> +#ifdef CONFIG_KASAN
> +void kasan_check_read(const void *p, unsigned int size);
> +void kasan_check_write(const void *p, unsigned int size);
> +#else
> +static inline void kasan_check_read(const void *p, unsigned int size) { }
> +static inline void kasan_check_write(const void *p, unsigned int size) { }
> +#endif
> +
> +#endif
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index b7397b459960..1cdcab0c976a 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -274,6 +274,18 @@ static __always_inline void check_memory_region(unsigned long addr,
> void __asan_loadN(unsigned long addr, size_t size);
> void __asan_storeN(unsigned long addr, size_t size);
>
> +void kasan_check_read(const void *p, unsigned int size)
> +{
> + check_memory_region((unsigned long)p, size, false);
> +}
> +EXPORT_SYMBOL(kasan_check_read);
> +
> +void kasan_check_write(const void *p, unsigned int size)
> +{
> + check_memory_region((unsigned long)p, size, true);
> +}
> +EXPORT_SYMBOL(kasan_check_write);
> +
> #undef memset
> void *memset(void *addr, int c, size_t len)
> {
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 ARM64 v4.4 V3 08/44] arm64: uaccess: Don't bother eliding access_ok checks in __{get, put}_user
From: Mark Rutland @ 2019-08-30 9:41 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <40fe1d91c9cd8d78ae952b821185681621f92b10.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:53PM +0530, Viresh Kumar wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> commit 84624087dd7e3b482b7b11c170ebc1f329b3a218 upstream.
>
> access_ok isn't an expensive operation once the addr_limit for the current
> thread has been loaded into the cache. Given that the initial access_ok
> check preceding a sequence of __{get,put}_user operations will take
> the brunt of the miss, we can make the __* variants identical to the
> full-fat versions, which brings with it the benefits of address masking.
>
> The likely cost in these sequences will be from toggling PAN/UAO, which
> we can address later by implementing the *_unsafe versions.
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> [ v4.4: Fixed conflicts around {__get_user|__put_user}_unaligned macros ]
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> arch/arm64/include/asm/uaccess.h | 62 ++++++++++++++++++--------------
> 1 file changed, 36 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index fc11c50af558..a34324436ce1 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -200,30 +200,35 @@ do { \
> CONFIG_ARM64_PAN)); \
> } while (0)
>
> -#define __get_user(x, ptr) \
> +#define __get_user_check(x, ptr, err) \
> ({ \
> - int __gu_err = 0; \
> - __get_user_err((x), (ptr), __gu_err); \
> - __gu_err; \
> + __typeof__(*(ptr)) __user *__p = (ptr); \
> + might_fault(); \
> + if (access_ok(VERIFY_READ, __p, sizeof(*__p))) { \
> + __p = uaccess_mask_ptr(__p); \
> + __get_user_err((x), __p, (err)); \
> + } else { \
> + (x) = 0; (err) = -EFAULT; \
> + } \
> })
>
> #define __get_user_error(x, ptr, err) \
> ({ \
> - __get_user_err((x), (ptr), (err)); \
> + __get_user_check((x), (ptr), (err)); \
> (void)0; \
> })
>
> -#define __get_user_unaligned __get_user
> -
> -#define get_user(x, ptr) \
> +#define __get_user(x, ptr) \
> ({ \
> - __typeof__(*(ptr)) __user *__p = (ptr); \
> - might_fault(); \
> - access_ok(VERIFY_READ, __p, sizeof(*__p)) ? \
> - __p = uaccess_mask_ptr(__p), __get_user((x), __p) : \
> - ((x) = 0, -EFAULT); \
> + int __gu_err = 0; \
> + __get_user_check((x), (ptr), __gu_err); \
> + __gu_err; \
> })
>
> +#define __get_user_unaligned __get_user
> +
> +#define get_user __get_user
> +
> #define __put_user_asm(instr, reg, x, addr, err) \
> asm volatile( \
> "1: " instr " " reg "1, [%2]\n" \
> @@ -266,30 +271,35 @@ do { \
> CONFIG_ARM64_PAN)); \
> } while (0)
>
> -#define __put_user(x, ptr) \
> +#define __put_user_check(x, ptr, err) \
> ({ \
> - int __pu_err = 0; \
> - __put_user_err((x), (ptr), __pu_err); \
> - __pu_err; \
> + __typeof__(*(ptr)) __user *__p = (ptr); \
> + might_fault(); \
> + if (access_ok(VERIFY_WRITE, __p, sizeof(*__p))) { \
> + __p = uaccess_mask_ptr(__p); \
> + __put_user_err((x), __p, (err)); \
> + } else { \
> + (err) = -EFAULT; \
> + } \
> })
>
> #define __put_user_error(x, ptr, err) \
> ({ \
> - __put_user_err((x), (ptr), (err)); \
> + __put_user_check((x), (ptr), (err)); \
> (void)0; \
> })
>
> -#define __put_user_unaligned __put_user
> -
> -#define put_user(x, ptr) \
> +#define __put_user(x, ptr) \
> ({ \
> - __typeof__(*(ptr)) __user *__p = (ptr); \
> - might_fault(); \
> - access_ok(VERIFY_WRITE, __p, sizeof(*__p)) ? \
> - __p = uaccess_mask_ptr(__p), __put_user((x), __p) : \
> - -EFAULT; \
> + int __pu_err = 0; \
> + __put_user_check((x), (ptr), __pu_err); \
> + __pu_err; \
> })
>
> +#define __put_user_unaligned __put_user
> +
> +#define put_user __put_user
> +
> extern unsigned long __must_check __copy_from_user(void *to, const void __user *from, unsigned long n);
> extern unsigned long __must_check __copy_to_user(void __user *to, const void *from, unsigned long n);
> extern unsigned long __must_check __copy_in_user(void __user *to, const void __user *from, unsigned long n);
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 ARM64 v4.4 V3 07/44] arm64: uaccess: Prevent speculative use of the current addr_limit
From: Mark Rutland @ 2019-08-30 9:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <dbe69b13f77052abf5d342b2775b1ebdbcce241a.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:52PM +0530, Viresh Kumar wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> commit c2f0ad4fc089cff81cef6a13d04b399980ecbfcc upstream.
>
> A mispredicted conditional call to set_fs could result in the wrong
> addr_limit being forwarded under speculation to a subsequent access_ok
> check, potentially forming part of a spectre-v1 attack using uaccess
> routines.
>
> This patch prevents this forwarding from taking place, but putting heavy
> barriers in set_fs after writing the addr_limit.
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/uaccess.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index 75363d723262..fc11c50af558 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -62,6 +62,13 @@ extern int fixup_exception(struct pt_regs *regs);
> static inline void set_fs(mm_segment_t fs)
> {
> current_thread_info()->addr_limit = fs;
> +
> + /*
> + * Prevent a mispredicted conditional call to set_fs from forwarding
> + * the wrong address limit to access_ok under speculation.
> + */
> + dsb(nsh);
> + isb();
> }
>
> #define segment_eq(a, b) ((a) == (b))
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 ARM64 v4.4 V3 06/44] arm64: entry: Ensure branch through syscall table is bounded under speculation
From: Mark Rutland @ 2019-08-30 9:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <093a9777605bdd2ab2c33948a4e7a3fbb275de4d.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:51PM +0530, Viresh Kumar wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> commit 6314d90e64936c584f300a52ef173603fb2461b5 upstream.
>
> In a similar manner to array_index_mask_nospec, this patch introduces an
> assembly macro (mask_nospec64) which can be used to bound a value under
> speculation. This macro is then used to ensure that the indirect branch
> through the syscall table is bounded under speculation, with out-of-range
> addresses speculating as calls to sys_io_setup (0).
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> [ v4.4: use existing scno & sc_nr definitions ]
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/assembler.h | 11 +++++++++++
> arch/arm64/kernel/entry.S | 1 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index 683c2875278f..2b30363a3a89 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -102,6 +102,17 @@
> hint #20
> .endm
>
> +/*
> + * Sanitise a 64-bit bounded index wrt speculation, returning zero if out
> + * of bounds.
> + */
> + .macro mask_nospec64, idx, limit, tmp
> + sub \tmp, \idx, \limit
> + bic \tmp, \tmp, \idx
> + and \idx, \idx, \tmp, asr #63
> + csdb
> + .endm
> +
> #define USER(l, x...) \
> 9999: x; \
> .section __ex_table,"a"; \
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 4c5013b09dcb..e6aec982dea9 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -697,6 +697,7 @@ el0_svc_naked: // compat entry point
> b.ne __sys_trace
> cmp scno, sc_nr // check upper syscall limit
> b.hs ni_sys
> + mask_nospec64 scno, sc_nr, x19 // enforce bounds for syscall number
> ldr x16, [stbl, scno, lsl #3] // address in the syscall table
> blr x16 // call sys_* routine
> b ret_fast_syscall
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan @ 2019-08-30 9:40 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com, Jassi Brar,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190830093005.GA31297@bogus>
Hi Sudeep
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Fri, Aug 30, 2019 at 07:37:41AM +0000, Peng Fan wrote:
> > Hi Jassi,
> > > > I think there could be channel for TEE, and channel for Linux.
> > > > For virtualization case, there could be dedicated channel for each VM.
> > > >
> > > I am talking from Linux pov. Functions 0xfe and 0xff above, can't
> > > both be active at the same time, right?
> >
> > If I get your point correctly,
> > On UP, both could not be active. On SMP, tx/rx could be both active,
> > anyway this depends on secure firmware and Linux firmware design.
> >
>
> Just to confirm, we can't have SMC/HVC based Rx channel as there's no
> *architectural* way to achieve it. So it can be based on some interrupt from
> secure side and hence will be a *different* type of channel/controller.
>
> Sorry to make this point repeatedly, but juts to be absolutely clear:
> as it stands, SMC/HVC can be used only for Tx today.
Since interrupt notification was dropped in v5, I need to drop RX description
in v6.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
_______________________________________________
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 ARM64 v4.4 V3 05/44] arm64: Use pointer masking to limit uaccess speculation
From: Mark Rutland @ 2019-08-30 9:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <f26c719baa5df560360fb3bbb7483385dd5cb821.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:50PM +0530, Viresh Kumar wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> commit 4d8efc2d5ee4c9ccfeb29ee8afd47a8660d0c0ce upstream.
>
> Similarly to x86, mitigate speculation past an access_ok() check by
> masking the pointer against the address limit before use.
>
> Even if we don't expect speculative writes per se, it is plausible that
> a CPU may still speculate at least as far as fetching a cache line for
> writing, hence we also harden put_user() and clear_user() for peace of
> mind.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/uaccess.h | 26 +++++++++++++++++++++++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index c625cc5531fc..75363d723262 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -121,6 +121,26 @@ static inline unsigned long __range_ok(unsigned long addr, unsigned long size)
> #define access_ok(type, addr, size) __range_ok((unsigned long)(addr), size)
> #define user_addr_max get_fs
>
> +/*
> + * Sanitise a uaccess pointer such that it becomes NULL if above the
> + * current addr_limit.
> + */
> +#define uaccess_mask_ptr(ptr) (__typeof__(ptr))__uaccess_mask_ptr(ptr)
> +static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
> +{
> + void __user *safe_ptr;
> +
> + asm volatile(
> + " bics xzr, %1, %2\n"
> + " csel %0, %1, xzr, eq\n"
> + : "=&r" (safe_ptr)
> + : "r" (ptr), "r" (current_thread_info()->addr_limit)
> + : "cc");
> +
> + csdb();
> + return safe_ptr;
> +}
> +
> /*
> * The "__xxx" versions of the user access functions do not verify the address
> * space - it must have been done previously with a separate "access_ok()"
> @@ -193,7 +213,7 @@ do { \
> __typeof__(*(ptr)) __user *__p = (ptr); \
> might_fault(); \
> access_ok(VERIFY_READ, __p, sizeof(*__p)) ? \
> - __get_user((x), __p) : \
> + __p = uaccess_mask_ptr(__p), __get_user((x), __p) : \
> ((x) = 0, -EFAULT); \
> })
>
> @@ -259,7 +279,7 @@ do { \
> __typeof__(*(ptr)) __user *__p = (ptr); \
> might_fault(); \
> access_ok(VERIFY_WRITE, __p, sizeof(*__p)) ? \
> - __put_user((x), __p) : \
> + __p = uaccess_mask_ptr(__p), __put_user((x), __p) : \
> -EFAULT; \
> })
>
> @@ -297,7 +317,7 @@ static inline unsigned long __must_check copy_in_user(void __user *to, const voi
> static inline unsigned long __must_check clear_user(void __user *to, unsigned long n)
> {
> if (access_ok(VERIFY_WRITE, to, n))
> - n = __clear_user(to, n);
> + n = __clear_user(__uaccess_mask_ptr(to), n);
> return n;
> }
>
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 ARM64 v4.4 V3 04/44] arm64: Make USER_DS an inclusive limit
From: Mark Rutland @ 2019-08-30 9:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <55f8561f1ee207237fdcfbc8c5dc043be06d3de6.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:49PM +0530, Viresh Kumar wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> commit 51369e398d0d33e8f524314e672b07e8cf870e79 upstream.
>
> Currently, USER_DS represents an exclusive limit while KERNEL_DS is
> inclusive. In order to do some clever trickery for speculation-safe
> masking, we need them both to behave equivalently - there aren't enough
> bits to make KERNEL_DS exclusive, so we have precisely one option. This
> also happens to correct a longstanding false negative for a range
> ending on the very top byte of kernel memory.
>
> Mark Rutland points out that we've actually got the semantics of
> addresses vs. segments muddled up in most of the places we need to
> amend, so shuffle the {USER,KERNEL}_DS definitions around such that we
> can correct those properly instead of just pasting "-1"s everywhere.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> [ 4.4: Dropped changes from fault.c and fixed minor rebase conflict ]
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/processor.h | 3 ++
> arch/arm64/include/asm/uaccess.h | 45 +++++++++++++++++-------------
> arch/arm64/kernel/entry.S | 4 +--
> 3 files changed, 31 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 75d9ef6c457c..ff1449c25bf4 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -21,6 +21,9 @@
>
> #define TASK_SIZE_64 (UL(1) << VA_BITS)
>
> +#define KERNEL_DS UL(-1)
> +#define USER_DS (TASK_SIZE_64 - 1)
> +
> #ifndef __ASSEMBLY__
>
> /*
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index 829fa6d3e561..c625cc5531fc 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -56,10 +56,7 @@ struct exception_table_entry
>
> extern int fixup_exception(struct pt_regs *regs);
>
> -#define KERNEL_DS (-1UL)
> #define get_ds() (KERNEL_DS)
> -
> -#define USER_DS TASK_SIZE_64
> #define get_fs() (current_thread_info()->addr_limit)
>
> static inline void set_fs(mm_segment_t fs)
> @@ -87,22 +84,32 @@ static inline void set_fs(mm_segment_t fs)
> * Returns 1 if the range is valid, 0 otherwise.
> *
> * This is equivalent to the following test:
> - * (u65)addr + (u65)size <= current->addr_limit
> - *
> - * This needs 65-bit arithmetic.
> + * (u65)addr + (u65)size <= (u65)current->addr_limit + 1
> */
> -#define __range_ok(addr, size) \
> -({ \
> - unsigned long __addr = (unsigned long __force)(addr); \
> - unsigned long flag, roksum; \
> - __chk_user_ptr(addr); \
> - asm("adds %1, %1, %3; ccmp %1, %4, #2, cc; cset %0, ls" \
> - : "=&r" (flag), "=&r" (roksum) \
> - : "1" (__addr), "Ir" (size), \
> - "r" (current_thread_info()->addr_limit) \
> - : "cc"); \
> - flag; \
> -})
> +static inline unsigned long __range_ok(unsigned long addr, unsigned long size)
> +{
> + unsigned long limit = current_thread_info()->addr_limit;
> +
> + __chk_user_ptr(addr);
> + asm volatile(
> + // A + B <= C + 1 for all A,B,C, in four easy steps:
> + // 1: X = A + B; X' = X % 2^64
> + " adds %0, %0, %2\n"
> + // 2: Set C = 0 if X > 2^64, to guarantee X' > C in step 4
> + " csel %1, xzr, %1, hi\n"
> + // 3: Set X' = ~0 if X >= 2^64. For X == 2^64, this decrements X'
> + // to compensate for the carry flag being set in step 4. For
> + // X > 2^64, X' merely has to remain nonzero, which it does.
> + " csinv %0, %0, xzr, cc\n"
> + // 4: For X < 2^64, this gives us X' - C - 1 <= 0, where the -1
> + // comes from the carry in being clear. Otherwise, we are
> + // testing X' - C == 0, subject to the previous adjustments.
> + " sbcs xzr, %0, %1\n"
> + " cset %0, ls\n"
> + : "+r" (addr), "+r" (limit) : "Ir" (size) : "cc");
> +
> + return addr;
> +}
>
> /*
> * When dealing with data aborts, watchpoints, or instruction traps we may end
> @@ -111,7 +118,7 @@ static inline void set_fs(mm_segment_t fs)
> */
> #define untagged_addr(addr) sign_extend64(addr, 55)
>
> -#define access_ok(type, addr, size) __range_ok(addr, size)
> +#define access_ok(type, addr, size) __range_ok((unsigned long)(addr), size)
> #define user_addr_max get_fs
>
> /*
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index c849be9231bb..4c5013b09dcb 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -96,10 +96,10 @@
> .else
> add x21, sp, #S_FRAME_SIZE
> get_thread_info tsk
> - /* Save the task's original addr_limit and set USER_DS (TASK_SIZE_64) */
> + /* Save the task's original addr_limit and set USER_DS */
> ldr x20, [tsk, #TI_ADDR_LIMIT]
> str x20, [sp, #S_ORIG_ADDR_LIMIT]
> - mov x20, #TASK_SIZE_64
> + mov x20, #USER_DS
> str x20, [tsk, #TI_ADDR_LIMIT]
> .endif /* \el == 0 */
> mrs x22, elr_el1
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 ARM64 v4.4 V3 03/44] arm64: move TASK_* definitions to <asm/processor.h>
From: Mark Rutland @ 2019-08-30 9:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <687d13717c9736bc33b9128bd09371fc0453fbdd.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:48PM +0530, Viresh Kumar wrote:
> From: Yury Norov <ynorov@caviumnetworks.com>
>
> commit eef94a3d09aab437c8c254de942d8b1aa76455e2 upstream.
>
> ILP32 series [1] introduces the dependency on <asm/is_compat.h> for
> TASK_SIZE macro. Which in turn requires <asm/thread_info.h>, and
> <asm/thread_info.h> include <asm/memory.h>, giving a circular dependency,
> because TASK_SIZE is currently located in <asm/memory.h>.
>
> In other architectures, TASK_SIZE is defined in <asm/processor.h>, and
> moving TASK_SIZE there fixes the problem.
>
> Discussion: https://patchwork.kernel.org/patch/9929107/
>
> [1] https://github.com/norov/linux/tree/ilp32-next
>
> CC: Will Deacon <will.deacon@arm.com>
> CC: Laura Abbott <labbott@redhat.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/memory.h | 15 ---------------
> arch/arm64/include/asm/processor.h | 21 +++++++++++++++++++++
> arch/arm64/kernel/entry.S | 2 +-
> 3 files changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b42b930cc19a..959a1e9188fe 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -43,8 +43,6 @@
> * (VA_BITS - 1))
> * VA_BITS - the maximum number of bits for virtual addresses.
> * VA_START - the first kernel virtual address.
> - * TASK_SIZE - the maximum size of a user space task.
> - * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
> * The module space lives between the addresses given by TASK_SIZE
> * and PAGE_OFFSET - it must be within 128MB of the kernel text.
> */
> @@ -58,19 +56,6 @@
> #define PCI_IO_END (MODULES_VADDR - SZ_2M)
> #define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE)
> #define FIXADDR_TOP (PCI_IO_START - SZ_2M)
> -#define TASK_SIZE_64 (UL(1) << VA_BITS)
> -
> -#ifdef CONFIG_COMPAT
> -#define TASK_SIZE_32 UL(0x100000000)
> -#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
> - TASK_SIZE_32 : TASK_SIZE_64)
> -#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
> - TASK_SIZE_32 : TASK_SIZE_64)
> -#else
> -#define TASK_SIZE TASK_SIZE_64
> -#endif /* CONFIG_COMPAT */
> -
> -#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
>
> /*
> * Physical vs virtual RAM address space conversion. These are
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index d08559528927..75d9ef6c457c 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -19,6 +19,10 @@
> #ifndef __ASM_PROCESSOR_H
> #define __ASM_PROCESSOR_H
>
> +#define TASK_SIZE_64 (UL(1) << VA_BITS)
> +
> +#ifndef __ASSEMBLY__
> +
> /*
> * Default implementation of macro that returns current
> * instruction pointer ("program counter").
> @@ -36,6 +40,22 @@
> #include <asm/types.h>
>
> #ifdef __KERNEL__
> +/*
> + * TASK_SIZE - the maximum size of a user space task.
> + * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
> + */
> +#ifdef CONFIG_COMPAT
> +#define TASK_SIZE_32 UL(0x100000000)
> +#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
> + TASK_SIZE_32 : TASK_SIZE_64)
> +#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
> + TASK_SIZE_32 : TASK_SIZE_64)
> +#else
> +#define TASK_SIZE TASK_SIZE_64
> +#endif /* CONFIG_COMPAT */
> +
> +#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
> +
> #define STACK_TOP_MAX TASK_SIZE_64
> #ifdef CONFIG_COMPAT
> #define AARCH32_VECTORS_BASE 0xffff0000
> @@ -188,4 +208,5 @@ static inline void spin_lock_prefetch(const void *x)
>
> int cpu_enable_pan(void *__unused);
>
> +#endif /* __ASSEMBLY__ */
> #endif /* __ASM_PROCESSOR_H */
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 586326981769..c849be9231bb 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -27,7 +27,7 @@
> #include <asm/cpufeature.h>
> #include <asm/errno.h>
> #include <asm/esr.h>
> -#include <asm/memory.h>
> +#include <asm/processor.h>
> #include <asm/thread_info.h>
> #include <asm/asm-uaccess.h>
> #include <asm/unistd.h>
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 ARM64 v4.4 V3 02/44] arm64: Implement array_index_mask_nospec()
From: Mark Rutland @ 2019-08-30 9:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <a01785b993e2b39864ee0cab09695ae23a02b2f5.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:47PM +0530, Viresh Kumar wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> commit 022620eed3d0bc4bf2027326f599f5ad71c2ea3f upstream.
>
> Provide an optimised, assembly implementation of array_index_mask_nospec()
> for arm64 so that the compiler is not in a position to transform the code
> in ways which affect its ability to inhibit speculation (e.g. by introducing
> conditional branches).
>
> This is similar to the sequence used by x86, modulo architectural differences
> in the carry/borrow flags.
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/barrier.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
> index 574486634c62..7c25e3e11b6d 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -37,6 +37,27 @@
> #define dma_rmb() dmb(oshld)
> #define dma_wmb() dmb(oshst)
>
> +/*
> + * Generate a mask for array_index__nospec() that is ~0UL when 0 <= idx < sz
> + * and 0 otherwise.
> + */
> +#define array_index_mask_nospec array_index_mask_nospec
> +static inline unsigned long array_index_mask_nospec(unsigned long idx,
> + unsigned long sz)
> +{
> + unsigned long mask;
> +
> + asm volatile(
> + " cmp %1, %2\n"
> + " sbc %0, xzr, xzr\n"
> + : "=r" (mask)
> + : "r" (idx), "Ir" (sz)
> + : "cc");
> +
> + csdb();
> + return mask;
> +}
> +
> #define smp_mb() dmb(ish)
> #define smp_rmb() dmb(ishld)
> #define smp_wmb() dmb(ishst)
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 ARM64 v4.4 V3 01/44] arm64: barrier: Add CSDB macros to control data-value prediction
From: Mark Rutland @ 2019-08-30 9:39 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <4ba4e0d015f2e044e3eaf57e1239ae3e12d5a80e.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:46PM +0530, Viresh Kumar wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> commit 669474e772b952b14f4de4845a1558fd4c0414a4 upstream.
>
> For CPUs capable of data value prediction, CSDB waits for any outstanding
> predictions to architecturally resolve before allowing speculative execution
> to continue. Provide macros to expose it to the arch code.
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/assembler.h | 7 +++++++
> arch/arm64/include/asm/barrier.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index f68abb17aa4b..683c2875278f 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -95,6 +95,13 @@
> dmb \opt
> .endm
>
> +/*
> + * Value prediction barrier
> + */
> + .macro csdb
> + hint #20
> + .endm
> +
> #define USER(l, x...) \
> 9999: x; \
> .section __ex_table,"a"; \
> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
> index f2d2c0bbe21b..574486634c62 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -28,6 +28,8 @@
> #define dmb(opt) asm volatile("dmb " #opt : : : "memory")
> #define dsb(opt) asm volatile("dsb " #opt : : : "memory")
>
> +#define csdb() asm volatile("hint #20" : : : "memory")
> +
> #define mb() dsb(sy)
> #define rmb() dsb(ld)
> #define wmb() dsb(st)
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 2/8] videodev2.h: add V4L2_DEC_CMD_FLUSH
From: Alexandre Courbot @ 2019-08-30 9:38 UTC (permalink / raw)
To: Jernej Skrabec
Cc: devel, Linux Media Mailing List, Pawel Osciak, jonas, gregkh,
Chen-Yu Tsai, mripard, Tomasz Figa, Paul Kocialkowski,
Kyungmin Park, moderated list:ARM/Mediatek SoC support,
Hans Verkuil, Mauro Carvalho Chehab, Ezequiel Garcia, LKML,
Marek Szyprowski
In-Reply-To: <20190822194500.2071-3-jernej.skrabec@siol.net>
On Fri, Aug 23, 2019 at 4:45 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
>
> From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
>
> Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
>
> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++++++++++-
> Documentation/media/videodev2.h.rst.exceptions | 1 +
> include/uapi/linux/videodev2.h | 1 +
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> index 57f0066f4cff..0bffef6058f7 100644
> --- a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> @@ -208,7 +208,16 @@ introduced in Linux 3.3. They are, however, mandatory for stateful mem2mem decod
> been started yet, the driver will return an ``EPERM`` error code. When
> the decoder is already running, this command does nothing. No
> flags are defined for this command.
> -
> + * - ``V4L2_DEC_CMD_FLUSH``
> + - 4
> + - Flush any held capture buffers. Only valid for stateless decoders,
> + and only if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` was set.
> + This command is typically used when the application reached the
> + end of the stream and the last output buffer had the
> + ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
> + dequeueing the last capture buffer containing the last decoded frame.
> + So this command can be used to explicitly flush that last decoded
> + frame.
Just for safety, can we also specify that it is valid to call this
command even if no buffer was held (in which case it is a no-op), as
this can help make user-space code simpler?
>
> Return Value
> ============
> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
> index adeb6b7a15cb..a79028e4d929 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -434,6 +434,7 @@ replace define V4L2_DEC_CMD_START decoder-cmds
> replace define V4L2_DEC_CMD_STOP decoder-cmds
> replace define V4L2_DEC_CMD_PAUSE decoder-cmds
> replace define V4L2_DEC_CMD_RESUME decoder-cmds
> +replace define V4L2_DEC_CMD_FLUSH decoder-cmds
>
> replace define V4L2_DEC_CMD_START_MUTE_AUDIO decoder-cmds
> replace define V4L2_DEC_CMD_PAUSE_TO_BLACK decoder-cmds
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 4fa9f543742d..91a79e16089c 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1978,6 +1978,7 @@ struct v4l2_encoder_cmd {
> #define V4L2_DEC_CMD_STOP (1)
> #define V4L2_DEC_CMD_PAUSE (2)
> #define V4L2_DEC_CMD_RESUME (3)
> +#define V4L2_DEC_CMD_FLUSH (4)
>
> /* Flags for V4L2_DEC_CMD_START */
> #define V4L2_DEC_CMD_START_MUTE_AUDIO (1 << 0)
> --
> 2.22.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: [PATCHv1 0/3] Odroid c2 missing regulator linking
From: Anand Moon @ 2019-08-30 9:34 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, Martin Blumenstingl, Kevin Hilman, Linux Kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <101a12ac-1464-8864-4f8c-56bb46034a08@baylibre.com>
Hi Neil,
On Fri, 30 Aug 2019 at 13:01, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> On 29/08/2019 20:35, Anand Moon wrote:
> > Hi Neil,
> >
> > On Thu, 29 Aug 2019 at 13:58, Neil Armstrong <narmstrong@baylibre.com> wrote:
> >>
> >> On 28/08/2019 22:27, Anand Moon wrote:
> >>> Below small changes help re-configure or fix missing inter linking
> >>> of regulator node.
> >>>
> >>> Changes based top on my prevoius series.
> >>
> >> For the serie:
> >> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> >>
> >
> > Thanks for your review.
> >
> >>>
> >>> [0] https://patchwork.kernel.org/cover/11113091/
> >>>
> >>> TOOD: Add support for DVFS GXBB odroid board in next series.
> >>
> >> I'm curious how you will do this !
> >
> > I was just studying you previous series on how you have implemented
> > this feature for C1, N2 and VIM3 boards.
> >
> > [0] https://patchwork.kernel.org/cover/11114125/
> >
> > I started gathering key inputs needed for this ie *clk / pwm*
> > like VDDCPU and VDDE clk changes.
> >
> > But it looks like of the complex clk framework needed, so I leave this to the
> > expert like your team of developers to do this much quick and efficiently.
>
> On GXBB, GXL, GXM and AXG SoCs, CPU Frequency setting and PWM Regulator setup is
> done by the SCPI Co-processor via the SCPI protocol.
>
> Thus, we should not handle it from Linux, and even if we could, we don't have the
> registers documentation of the CPU clusters clock tree.
>
Ok thanks.
> SCPI works fine on all tested devices, except Odroid-C2, because Hardkernel left
> the > 1.5GHz freq in the initial SCPI tables loaded by the BL2, i.e. packed with U-Boot.
> Nowadays they have removed the bad frequencies, but still some devices uses the old
> bootloader.
>
> But in the SCPI case we trust the table returned by the firmware and use it as-in,
> and there is no (simple ?) way to override the table and set a max frequency.
>
> This is why we disabled SCPI.
>
> See https://patchwork.kernel.org/patch/9500175/
I have quickly enable this on my board and here the cpufreq info
[alarm@alarm ~]$ cpupower frequency-info
analyzing CPU 0:
driver: scpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 200 us
hardware limits: 100.0 MHz - 1.54 GHz
available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 1000 MHz,
1.30 GHz, 1.54 GHz
available cpufreq governors: conservative ondemand userspace
powersave performance schedutil
current policy: frequency should be within 100.0 MHz and 1.54 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 250 MHz (asserted by call to kernel)
I did some simple stress testing and observed the freq scaling is
working fine when cpufreq governor is set to ondemand.
Powertop output.
Package | CPU 0
100 MHz 5.2% | 100 MHz 1.6%
250 MHz 4.4% | 250 MHz 4.3%
500 MHz 2.6% | 500 MHz 2.4%
1000 MHz 0.5% | 1000 MHz 0.3%
1296 MHz 0.2% | 1296 MHz 0.1%
1.54 GHz 0.2% | 1.54 GHz 0.1%
Idle 86.9% | Idle 91.2%
Here the output on the linaro's pm-qa testing for cpufreq.
[1] https://pastebin.com/h880WATn
Almost all the test case pass with this one as off now.
Best Regards
-Anand
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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