* [PATCH v3 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
From: Robin Murphy @ 2017-05-03 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424085731.wbg53t5lcler4mng@kwain>
On 24/04/17 09:57, Antoine Tenart wrote:
> Hi Igal,
>
> On Mon, Apr 24, 2017 at 08:50:32AM +0000, Igal Liberman wrote:
>> [...]
>>
>>> + priv->clk = of_clk_get(dev->of_node, 0);
>>> + if (!IS_ERR(priv->clk)) {
>>> + ret = clk_prepare_enable(priv->clk);
>>> + if (ret) {
>>> + dev_err(dev, "unable to enable clk (%d)\n", ret);
>>> + return ret;
>>> + }
>>> + } else {
>>> + /* The clock isn't mandatory */
>>> + if (PTR_ERR(priv->clk) == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>> + }
>>> +
>>> + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
>>
>> The correct address width of the engine in Marvell SoCs is 40bit.
Is that what the IP block itself is internally limited to, or just how
many bits happen to be wired up externally in the particular Marvell
integrations?
> Oops. I'll update.
If the device itself can handle full 64-bit addresses, then the driver
should reflect that regardless of the integration - describing
integration limitations is the job of the firmware, e.g. with DT
"dma-ranges", assuming they actually matter (typically if the whole SoC
interconnect and physical memory map is the same width then having an
even wider DMA mask doesn't make any difference - 64 bits still just
means "everything").
If it's the case that the IP is configurable and could be synthesised
with various internal address widths, then that might warrant a DT
property to identify the particular configuration if it's not readable
from some ID register, although it may be reasonable in practice to
simply assume the chosen configuration to be sane (i.e. not smaller than
the rest of the system) and that the driver can set the maximal DMA mask
as above.
Robin.
>
> Thanks!
> Antoine
>
^ permalink raw reply
* [PATCH] [v2] MAINTAINERS: arm64 defconfig changes should go to arm@kernel.org
From: Catalin Marinas @ 2017-05-03 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493830346-16406-1-git-send-email-timur@codeaurora.org>
On Wed, May 03, 2017 at 11:52:26AM -0500, Timur Tabi wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 58590cf..5d15858 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2066,6 +2066,11 @@ S: Maintained
> F: arch/arm64/
> F: Documentation/arm64/
>
> +ARM64 DEFCONFIG
> +M: arm at kernel.org
> +S: Maintained
> +F: arch/arm64/configs/defconfig
You need an 'L' entry as well (linux-arm-kernel at lists.infradead.org).
--
Catalin
^ permalink raw reply
* [PATCH] [v2] MAINTAINERS: arm64 defconfig changes should go to arm@kernel.org
From: Olof Johansson @ 2017-05-03 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503171704.GD23620@e104818-lin.cambridge.arm.com>
On Wed, May 3, 2017 at 10:17 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Wed, May 03, 2017 at 11:52:26AM -0500, Timur Tabi wrote:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 58590cf..5d15858 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2066,6 +2066,11 @@ S: Maintained
>> F: arch/arm64/
>> F: Documentation/arm64/
>>
>> +ARM64 DEFCONFIG
>> +M: arm at kernel.org
>> +S: Maintained
>> +F: arch/arm64/configs/defconfig
>
> You need an 'L' entry as well (linux-arm-kernel at lists.infradead.org).
NAK on this patch. See other reply.
-Olof
^ permalink raw reply
* [PATCH] MAINTAINERS: add arm@kernel.org as the list for arm64 defconfig changes
From: Olof Johansson @ 2017-05-03 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95597ce9-a46f-1491-ae65-518ed8b8c44c@codeaurora.org>
Hello,
On Wed, May 3, 2017 at 10:08 AM, Timur Tabi <timur@codeaurora.org> wrote:
> On 05/03/2017 12:01 PM, Catalin Marinas wrote:
>> On Wed, May 03, 2017 at 11:31:25AM -0500, Timur Tabi wrote:
>>> > Any changes to arch/arm64/configs/defconfig must be sent to arm at kernel.org,
>>> > otherwise they will not get picked up. Add a MAINTAINERS entry to ensure
>>> > the get_maintainers includes it.
>> There are other patches that go through arm at kernel.org like
>> arch/arm64/boot/dts/ but the arm-soc guys didn't want a MAINTAINERS
>> entry (I don't remember the reasons).
>
> I'm happy to add additional paths/files, but without a MAINTAINERS entry,
> how would anyone know to CC: that address? I posted 3 versions of my
> defconfig patchset before someone told me that I had to send it to
> arm at kernel.org.
arm at kernel.org as an email alias will break down if it starts being
cc:d on large number of patches. Ideally we want the platform
maintainers as filters/reviewers in front to keep the volume down. So
far it's been kept to nearly only material from maintainers, and
mostly pull requests.
Defconfig changes usually come in through maintainers. Said
maintainers already know to send code to us at arm at kernel.org for
their platforms. So this should probably go in through Andy Gross? You
didn't even cc him, so added now.
> Anyway, I really hope it's not too late for my defconfig changes to make
> 4.12. Please consider them. Thank you.
We won't consider any patches at this very time, since we're in the
middle of the merge window. Main priority right now is to prepare the
material we have for pull requests and merge.
This is not the time to send us new material, but you probably already
know that.
-Olof
^ permalink raw reply
* [PATCH] MAINTAINERS: add arm@kernel.org as the list for arm64 defconfig changes
From: Timur Tabi @ 2017-05-03 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMiY9o8199bb13gsd3SAs8YR-4rafYHoyV3VmK0dY0MDtQ@mail.gmail.com>
On 05/03/2017 12:26 PM, Olof Johansson wrote:
> arm at kernel.org as an email alias will break down if it starts being
> cc:d on large number of patches. Ideally we want the platform
> maintainers as filters/reviewers in front to keep the volume down. So
> far it's been kept to nearly only material from maintainers, and
> mostly pull requests.
>
> Defconfig changes usually come in through maintainers. Said
> maintainers already know to send code to us at arm at kernel.org for
> their platforms. So this should probably go in through Andy Gross? You
> didn't even cc him, so added now.
How would I know to CC: him, or anyone else, without a MAINTAINERS entry?
I've already posted these patches 5 times, and every time I do, someone
tells me that I'm CCing the wrong person.
Are you saying that I should send the 9 patches to 9 different people, and
just pray that they all get merged in properly? Each of the maintainers is
going to ask for an ACK from an ARM maintainer anyway, whoever he is (I
don't know any more).
There's got to be a better way.
> We won't consider any patches at this very time, since we're in the
> middle of the merge window. Main priority right now is to prepare the
> material we have for pull requests and merge.
>
> This is not the time to send us new material, but you probably already
> know that.
Fair enough, but the patches aren't new. They've been been floating on the
list for three weeks now.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] MAINTAINERS: add arm@kernel.org as the list for arm64 defconfig changes
From: Olof Johansson @ 2017-05-03 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b048ba1-b7e4-6ab6-95be-3163120f63aa@codeaurora.org>
On Wed, May 3, 2017 at 10:33 AM, Timur Tabi <timur@codeaurora.org> wrote:
> On 05/03/2017 12:26 PM, Olof Johansson wrote:
>> arm at kernel.org as an email alias will break down if it starts being
>> cc:d on large number of patches. Ideally we want the platform
>> maintainers as filters/reviewers in front to keep the volume down. So
>> far it's been kept to nearly only material from maintainers, and
>> mostly pull requests.
>>
>> Defconfig changes usually come in through maintainers. Said
>> maintainers already know to send code to us at arm at kernel.org for
>> their platforms. So this should probably go in through Andy Gross? You
>> didn't even cc him, so added now.
>
> How would I know to CC: him, or anyone else, without a MAINTAINERS entry?
> I've already posted these patches 5 times, and every time I do, someone
> tells me that I'm CCing the wrong person.
There's a handy tool called get_maintainer:
olof at brutus:~/work/linux ((52aa3ec...)) $ ./scripts/get_maintainer.pl
-f arch/arm64/configs/defconfig
Catalin Marinas <catalin.marinas@arm.com> (maintainer:ARM64 PORT
(AARCH64 ARCHITECTURE),commit_signer:6/61=10%)
Will Deacon <will.deacon@arm.com> (maintainer:ARM64 PORT (AARCH64 ARCHITECTURE))
Arnd Bergmann <arnd@arndb.de> (commit_signer:10/61=16%)
Kevin Hilman <khilman@baylibre.com> (commit_signer:9/61=15%,authored:6/61=10%)
Olof Johansson <olof@lixom.net> (commit_signer:6/61=10%)
Wei Xu <xuwei5@hisilicon.com> (commit_signer:6/61=10%)
If you read the output, you can see that the people who have applied
most of these patches have been Will, Arnd, Kevin and myself. Adding
those on Cc could have been a good first step.
> Are you saying that I should send the 9 patches to 9 different people, and
> just pray that they all get merged in properly? Each of the maintainers is
> going to ask for an ACK from an ARM maintainer anyway, whoever he is (I
> don't know any more).
>
> There's got to be a better way.
No, I'm not saying that, and there is a better way: Send it through
Andy if in doubt -- it should be his job as your platform maintainer
to help guide you through the system if needed.
>> We won't consider any patches at this very time, since we're in the
>> middle of the merge window. Main priority right now is to prepare the
>> material we have for pull requests and merge.
>>
>> This is not the time to send us new material, but you probably already
>> know that.
>
> Fair enough, but the patches aren't new. They've been been floating on the
> list for three weeks now.
While I understand your frustration, this is also not how it works at our end.
Sometimes we tweak defconfigs late in the merge window and sometimes
even during early -rc, so let us get back to this after we've handled
the merges.
-Olof
^ permalink raw reply
* [PATCH] MAINTAINERS: add arm@kernel.org as the list for arm64 defconfig changes
From: Timur Tabi @ 2017-05-03 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgnOQXtLT8aUvPhXDfShzhkP-3LWFhP60xiMn65x6aq=w@mail.gmail.com>
On 05/03/2017 12:39 PM, Olof Johansson wrote:
> No, I'm not saying that, and there is a better way: Send it through
> Andy if in doubt -- it should be his job as your platform maintainer
> to help guide you through the system if needed.
Will told me that defconfig patches should go to arm at kernel.org, but you're
telling me they should go to Andy instead.
Andy's being the platform maintainer is news to me. I'm not saying he
isn't, but I can't remember the last time I involved him in any patches of ours.
Either way, I think there should be a designated maintainer for
arch/arm64/configs/defconfig, and I think that person/alias should be in
MAINTAINERS.
> Sometimes we tweak defconfigs late in the merge window and sometimes
> even during early -rc, so let us get back to this after we've handled
> the merges.
Ok, thank you.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
From: Leonard Crestez @ 2017-05-03 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e46a57c2-4a28-a8b6-445e-299dd9d8659c@denx.de>
On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> > On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
> > > 2) It actually fixes a problem with the voltage rails such that the DVFS
> > > ???works without leaving the system in unstable or dead state. You do
> > > ???need the second part of my patch if you drop the OPP hackery, without
> > > ???it the power framework cannot correctly configure the core voltages,
> > > ???so the patch from Leonard makes things worse.
> > No, I think there is a misunderstanding here. The second part of your
> > patch will cause cpufreq poking at LDOs to indirectly adjust the input
> > from the PMIC to the minimum required (this is LDO target +
> > min_dropout_uv). Without it by default VDD_ARM_SOC_IN will remain fixed
> > as 1375mV from boot.
> Who sets / guarantees that default value for ARM and SOC rails ?
I think it's from the PMIC hardware itself (but maybe uboot plays with
it). VDD_ARM_SOC_IN on this board is tied to SW1AB from MMPF0200:
http://www.nxp.com/assets/documents/data/en/data-sheets/MMPF0200.pdf
It seems reasonable to rely on such voltages set externally.
> With the OPP override in place, there's at least the guarantee that both
> rails will have the same voltage requirement. If you remove the OPP
> override without modeling the actual regulator wiring, the guarantee is
> gone.
The imx6sx chip has internal LDO_ARM and LDO_SOC regulators which can
generate separate voltages for arm/soc. The fact that these regulators
share the same supply is only an issue when they are set in bypass
mode.
However the boot issues happen on REV C but apparently not REV B of the
board. I don't have a good explanation for this so maybe I am missing
something.
--?
Regards,
Leonard
^ permalink raw reply
* [PATCH 0/5] Userspace timer IRQ number control and PMU with userspace-gic
From: Christoffer Dall @ 2017-05-03 18:32 UTC (permalink / raw)
To: linux-arm-kernel
So far we have been getting away with letting the kernel choosing
interrupt numbers for the timers in the kernel and we have crossed our
fingers in hoping that the DT/ACPI provided by userspace matches with
the interrupt number we use in the kernel for a given VCPU type.
But as we are generally moving towards letting userspace be in more fine
grained control of what is being emulated, let userspace decide the irq
numbers for the timers.
Slightly related, and therefore included in this series, we have
recently added support for a userspace GIC while still supporting the
generic timers and the PMU from inside the VM. Unfortunately we forgot
to rework the code to actually let userspace create the PMU device
without creating an in-kernel GIC.
Tested on APM X-Gene, AMD Seattle, and TC2.
QEMU patches used for testing can be found here:
https://git.linaro.org/people/christoffer.dall/qemu-arm.git timer-pmu-irqs
Thanks,
-Christoffer
Christoffer Dall (5):
KVM: arm64: Allow creating the PMU without the in-kernel GIC
KVM: arm: Handle VCPU device attributes in guest.c
KVM: arm/arm64: Move irq_is_ppi() to header file
KVM: arm/arm64: Move timer IRQ default init to arch_timer.c
KVM: arm/arm64: Allow setting the timer IRQ numbers from userspace
Documentation/virtual/kvm/devices/vcpu.txt | 41 +++++++--
arch/arm/include/asm/kvm_host.h | 22 ++---
arch/arm/include/uapi/asm/kvm.h | 8 ++
arch/arm/kvm/guest.c | 51 +++++++++++
arch/arm/kvm/reset.c | 16 +---
arch/arm64/include/uapi/asm/kvm.h | 3 +
arch/arm64/kvm/guest.c | 9 ++
arch/arm64/kvm/reset.c | 16 +---
include/kvm/arm_arch_timer.h | 8 +-
include/kvm/arm_vgic.h | 2 +
virt/kvm/arm/arch_timer.c | 132 ++++++++++++++++++++++++++---
virt/kvm/arm/pmu.c | 29 ++++---
12 files changed, 258 insertions(+), 79 deletions(-)
--
2.9.0
^ permalink raw reply
* [PATCH 1/5] KVM: arm64: Allow creating the PMU without the in-kernel GIC
From: Christoffer Dall @ 2017-05-03 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503183300.4618-1-cdall@linaro.org>
Since we got support for devices in userspace which allows reporting the
PMU overflow output status to userspace, we should actually allow
creating the PMU on systems without an in-kernel irqchip, which in turn
requires us to slightly clarify error codes for the ABI and move things
around for the initialization phase.
Signed-off-by: Christoffer Dall <cdall@linaro.org>
---
Documentation/virtual/kvm/devices/vcpu.txt | 16 +++++++++-------
virt/kvm/arm/pmu.c | 27 +++++++++++++++++----------
2 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
index 02f5068..352af6e 100644
--- a/Documentation/virtual/kvm/devices/vcpu.txt
+++ b/Documentation/virtual/kvm/devices/vcpu.txt
@@ -16,7 +16,9 @@ Parameters: in kvm_device_attr.addr the address for PMU overflow interrupt is a
Returns: -EBUSY: The PMU overflow interrupt is already set
-ENXIO: The overflow interrupt not set when attempting to get it
-ENODEV: PMUv3 not supported
- -EINVAL: Invalid PMU overflow interrupt number supplied
+ -EINVAL: Invalid PMU overflow interrupt number supplied or
+ trying to set the IRQ number without using an in-kernel
+ irqchip.
A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt
number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt
@@ -25,11 +27,11 @@ all vcpus, while as an SPI it must be a separate number per vcpu.
1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT
Parameters: no additional parameter in kvm_device_attr.addr
-Returns: -ENODEV: PMUv3 not supported
- -ENXIO: PMUv3 not properly configured as required prior to calling this
- attribute
+Returns: -ENODEV: PMUv3 not supported or GIC not initialized
+ -ENXIO: PMUv3 not properly configured or in-kernel irqchip not
+ conigured as required prior to calling this attribute
-EBUSY: PMUv3 already initialized
-Request the initialization of the PMUv3. This must be done after creating the
-in-kernel irqchip. Creating a PMU with a userspace irqchip is currently not
-supported.
+Request the initialization of the PMUv3. If using the PMUv3 with an in-kernel
+virtual GIC implementation, this must be done after initializing the in-kernel
+irqchip.
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 4b43e7f..f046b08 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -456,21 +456,25 @@ static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
if (!kvm_arm_support_pmu_v3())
return -ENODEV;
- /*
- * We currently require an in-kernel VGIC to use the PMU emulation,
- * because we do not support forwarding PMU overflow interrupts to
- * userspace yet.
- */
- if (!irqchip_in_kernel(vcpu->kvm) || !vgic_initialized(vcpu->kvm))
- return -ENODEV;
-
- if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features) ||
- !kvm_arm_pmu_irq_initialized(vcpu))
+ if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
return -ENXIO;
if (kvm_arm_pmu_v3_ready(vcpu))
return -EBUSY;
+ if (irqchip_in_kernel(vcpu->kvm)) {
+ /*
+ * If using the PMU with an in-kernel virtual GIC
+ * implementation, we require the GIC to be already
+ * initialized when initializing the PMU.
+ */
+ if (!vgic_initialized(vcpu->kvm))
+ return -ENODEV;
+
+ if (!kvm_arm_pmu_irq_initialized(vcpu))
+ return -ENXIO;
+ }
+
kvm_pmu_vcpu_reset(vcpu);
vcpu->arch.pmu.ready = true;
@@ -512,6 +516,9 @@ int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
int __user *uaddr = (int __user *)(long)attr->addr;
int irq;
+ if (!irqchip_in_kernel(vcpu->kvm))
+ return -EINVAL;
+
if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
return -ENODEV;
--
2.9.0
^ permalink raw reply related
* [PATCH 2/5] KVM: arm: Handle VCPU device attributes in guest.c
From: Christoffer Dall @ 2017-05-03 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503183300.4618-1-cdall@linaro.org>
As we are about to support VCPU attributes to set the timer IRQ numbers
in guest.c, move the static inlines for the VCPU attributes handlers
from the header file to guest.c.
Signed-off-by: Christoffer Dall <cdall@linaro.org>
---
arch/arm/include/asm/kvm_host.h | 22 +++++++--------------
arch/arm/kvm/guest.c | 42 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index d488b88..0e8c233 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -292,20 +292,12 @@ static inline void kvm_arm_init_debug(void) {}
static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
-static inline int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
- struct kvm_device_attr *attr)
-{
- return -ENXIO;
-}
-static inline int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
- struct kvm_device_attr *attr)
-{
- return -ENXIO;
-}
-static inline int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
- struct kvm_device_attr *attr)
-{
- return -ENXIO;
-}
+
+int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+ struct kvm_device_attr *attr);
+int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+ struct kvm_device_attr *attr);
+int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+ struct kvm_device_attr *attr);
#endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index fa6182a..acea05e 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -301,3 +301,45 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
{
return -EINVAL;
}
+
+int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+ struct kvm_device_attr *attr)
+{
+ int ret;
+
+ switch (attr->group) {
+ default:
+ ret = -ENXIO;
+ break;
+ }
+
+ return ret;
+}
+
+int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+ struct kvm_device_attr *attr)
+{
+ int ret;
+
+ switch (attr->group) {
+ default:
+ ret = -ENXIO;
+ break;
+ }
+
+ return ret;
+}
+
+int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+ struct kvm_device_attr *attr)
+{
+ int ret;
+
+ switch (attr->group) {
+ default:
+ ret = -ENXIO;
+ break;
+ }
+
+ return ret;
+}
--
2.9.0
^ permalink raw reply related
* [PATCH 3/5] KVM: arm/arm64: Move irq_is_ppi() to header file
From: Christoffer Dall @ 2017-05-03 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503183300.4618-1-cdall@linaro.org>
We are about to need this define in the arch timer code as well so move
it to a common location.
Signed-off-by: Christoffer Dall <cdall@linaro.org>
---
include/kvm/arm_vgic.h | 2 ++
virt/kvm/arm/pmu.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 26ed4fb..1541f5d 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -38,6 +38,8 @@
#define VGIC_MIN_LPI 8192
#define KVM_IRQCHIP_NUM_PINS (1020 - 32)
+#define irq_is_ppi(irq) ((irq) >= VGIC_NR_SGIS && (irq) < VGIC_NR_PRIVATE_IRQS)
+
enum vgic_type {
VGIC_V2, /* Good ol' GICv2 */
VGIC_V3, /* New fancy GICv3 */
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index f046b08..9b3e3ea 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -481,8 +481,6 @@ static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
return 0;
}
-#define irq_is_ppi(irq) ((irq) >= VGIC_NR_SGIS && (irq) < VGIC_NR_PRIVATE_IRQS)
-
/*
* For one VM the interrupt type must be same for each vcpu.
* As a PPI, the interrupt number is the same for all vcpus,
--
2.9.0
^ permalink raw reply related
* [PATCH 4/5] KVM: arm/arm64: Move timer IRQ default init to arch_timer.c
From: Christoffer Dall @ 2017-05-03 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503183300.4618-1-cdall@linaro.org>
We currently initialize the arch timer IRQ numbers from the reset code,
presumably because we once intended to model multiple CPU or SoC types
from within the kernel and have hard-coded reset values in the reset
code.
As we are moving towards userspace being in charge of more fine-grained
CPU emulation and stitching together the pieces needed to emulate a
particular type of CPU, we should no longer have a tight coupling
between resetting a VCPU and setting IRQ numbers.
Therefore, move the logic to define and use the default IRQ numbers to
the timer code and set the IRQ number immediately when creating the
VCPU.
Signed-off-by: Christoffer Dall <cdall@linaro.org>
---
arch/arm/kvm/reset.c | 16 +---------------
arch/arm64/kvm/reset.c | 16 +---------------
include/kvm/arm_arch_timer.h | 4 +---
virt/kvm/arm/arch_timer.c | 28 ++++++++++++++++------------
4 files changed, 19 insertions(+), 45 deletions(-)
diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
index 1da8b2d..5ed0c3e 100644
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@ -37,16 +37,6 @@ static struct kvm_regs cortexa_regs_reset = {
.usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
};
-static const struct kvm_irq_level cortexa_ptimer_irq = {
- { .irq = 30 },
- .level = 1,
-};
-
-static const struct kvm_irq_level cortexa_vtimer_irq = {
- { .irq = 27 },
- .level = 1,
-};
-
/*******************************************************************************
* Exported reset function
@@ -62,16 +52,12 @@ static const struct kvm_irq_level cortexa_vtimer_irq = {
int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
{
struct kvm_regs *reset_regs;
- const struct kvm_irq_level *cpu_vtimer_irq;
- const struct kvm_irq_level *cpu_ptimer_irq;
switch (vcpu->arch.target) {
case KVM_ARM_TARGET_CORTEX_A7:
case KVM_ARM_TARGET_CORTEX_A15:
reset_regs = &cortexa_regs_reset;
vcpu->arch.midr = read_cpuid_id();
- cpu_vtimer_irq = &cortexa_vtimer_irq;
- cpu_ptimer_irq = &cortexa_ptimer_irq;
break;
default:
return -ENODEV;
@@ -84,5 +70,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
kvm_reset_coprocs(vcpu);
/* Reset arch_timer context */
- return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
+ return kvm_timer_vcpu_reset(vcpu);
}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index d9e9697..4942de2 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -46,16 +46,6 @@ static const struct kvm_regs default_regs_reset32 = {
COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
};
-static const struct kvm_irq_level default_ptimer_irq = {
- .irq = 30,
- .level = 1,
-};
-
-static const struct kvm_irq_level default_vtimer_irq = {
- .irq = 27,
- .level = 1,
-};
-
static bool cpu_has_32bit_el1(void)
{
u64 pfr0;
@@ -108,8 +98,6 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
*/
int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
{
- const struct kvm_irq_level *cpu_vtimer_irq;
- const struct kvm_irq_level *cpu_ptimer_irq;
const struct kvm_regs *cpu_reset;
switch (vcpu->arch.target) {
@@ -122,8 +110,6 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
cpu_reset = &default_regs_reset;
}
- cpu_vtimer_irq = &default_vtimer_irq;
- cpu_ptimer_irq = &default_ptimer_irq;
break;
}
@@ -137,5 +123,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
kvm_pmu_vcpu_reset(vcpu);
/* Reset timer */
- return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
+ return kvm_timer_vcpu_reset(vcpu);
}
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index 295584f..f1c967a 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -57,9 +57,7 @@ struct arch_timer_cpu {
int kvm_timer_hyp_init(void);
int kvm_timer_enable(struct kvm_vcpu *vcpu);
-int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
- const struct kvm_irq_level *virt_irq,
- const struct kvm_irq_level *phys_irq);
+int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu);
void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 5976609..6c5a064 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -35,6 +35,16 @@ static struct timecounter *timecounter;
static unsigned int host_vtimer_irq;
static u32 host_vtimer_irq_flags;
+static const struct kvm_irq_level default_ptimer_irq = {
+ .irq = 30,
+ .level = 1,
+};
+
+static const struct kvm_irq_level default_vtimer_irq = {
+ .irq = 27,
+ .level = 1,
+};
+
void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu)
{
vcpu_vtimer(vcpu)->active_cleared_last = false;
@@ -445,23 +455,12 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
kvm_timer_update_state(vcpu);
}
-int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
- const struct kvm_irq_level *virt_irq,
- const struct kvm_irq_level *phys_irq)
+int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
/*
- * The vcpu timer irq number cannot be determined in
- * kvm_timer_vcpu_init() because it is called much before
- * kvm_vcpu_set_target(). To handle this, we determine
- * vcpu timer irq number when the vcpu is reset.
- */
- vtimer->irq.irq = virt_irq->irq;
- ptimer->irq.irq = phys_irq->irq;
-
- /*
* The bits in CNTV_CTL are architecturally reset to UNKNOWN for ARMv8
* and to 0 for ARMv7. We provide an implementation that always
* resets the timer to be disabled and unmasked and is compliant with
@@ -496,6 +495,8 @@ static void update_vtimer_cntvoff(struct kvm_vcpu *vcpu, u64 cntvoff)
void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+ struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
+ struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
/* Synchronize cntvoff across all vtimers of a VM. */
update_vtimer_cntvoff(vcpu, kvm_phys_timer_read());
@@ -504,6 +505,9 @@ void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
INIT_WORK(&timer->expired, kvm_timer_inject_irq_work);
hrtimer_init(&timer->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
timer->timer.function = kvm_timer_expire;
+
+ vtimer->irq.irq = default_vtimer_irq.irq;
+ ptimer->irq.irq = default_ptimer_irq.irq;
}
static void kvm_timer_init_interrupt(void *info)
--
2.9.0
^ permalink raw reply related
* [PATCH 5/5] KVM: arm/arm64: Allow setting the timer IRQ numbers from userspace
From: Christoffer Dall @ 2017-05-03 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503183300.4618-1-cdall@linaro.org>
First we define an ABI using the vcpu devices that lets userspace set
the interrupt numbers for the various timers on both the 32-bit and
64-bit KVM/ARM implementations.
Second, we add the definitions for the groups and attributes introduced
by the above ABI. (We add the PMU define on the 32-bit side as well for
symmetry and it may get used some day.)
Third, we set up the arch-specific vcpu device operation handlers to
call into the timer code for anything related to the
KVM_ARM_VCPU_TIMER_CTRL group.
Fourth, we implement support for getting and setting the timer interrupt
numbers using the above defined ABI in the arch timer code.
Fifth, we introduce error checking upon enabling the arch timer (which
is called when first running a VCPU) to check that all VCPUs are
configured to use the same PPI for the timer (as mandated by the
architecture) and that the virtual and physical timers are not
configured to use the same IRQ number.
Signed-off-by: Christoffer Dall <cdall@linaro.org>
---
Documentation/virtual/kvm/devices/vcpu.txt | 25 +++++++
arch/arm/include/uapi/asm/kvm.h | 8 +++
arch/arm/kvm/guest.c | 9 +++
arch/arm64/include/uapi/asm/kvm.h | 3 +
arch/arm64/kvm/guest.c | 9 +++
include/kvm/arm_arch_timer.h | 4 ++
virt/kvm/arm/arch_timer.c | 104 +++++++++++++++++++++++++++++
7 files changed, 162 insertions(+)
diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
index 352af6e..013e3f1 100644
--- a/Documentation/virtual/kvm/devices/vcpu.txt
+++ b/Documentation/virtual/kvm/devices/vcpu.txt
@@ -35,3 +35,28 @@ Returns: -ENODEV: PMUv3 not supported or GIC not initialized
Request the initialization of the PMUv3. If using the PMUv3 with an in-kernel
virtual GIC implementation, this must be done after initializing the in-kernel
irqchip.
+
+
+2. GROUP: KVM_ARM_VCPU_TIMER_CTRL
+Architectures: ARM,ARM64
+
+2.1. ATTRIBUTE: KVM_ARM_VCPU_TIMER_IRQ_VTIMER
+2.2. ATTRIBUTE: KVM_ARM_VCPU_TIMER_IRQ_PTIMER
+Parameters: in kvm_device_attr.addr the address for the timer interrupt is a
+ pointer to an int
+Returns: -EINVAL: Invalid timer interrupt number
+ -EBUSY: One or more VCPUs has already run
+
+A value describing the architected timer interrupt number when connected to an
+in-kernel virtual GIC. These must be a PPI (16 <= intid < 32). If an
+attribute is not set, a default value is applied (see below).
+
+KVM_ARM_VCPU_TIMER_IRQ_VTIMER: The EL1 virtual timer intid (default: 27)
+KVM_ARM_VCPU_TIMER_IRQ_PTIMER: The EL1 physical timer intid (default: 30)
+
+Setting the same PPI for different timers will prevent the VCPUs from running.
+Setting the interrupt number on a VCPU configures all VCPUs created at that
+time to use the number provided for a given timer, overwriting any previously
+configured values on other VCPUs. Userspace should configure the interrupt
+numbers on@least one VCPU after creating all VCPUs and before running any
+VCPUs.
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index a5838d6..6a75ec4 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -200,6 +200,14 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK 0x3ff
#define VGIC_LEVEL_INFO_LINE_LEVEL 0
+/* Device Control API on vcpu fd */
+#define KVM_ARM_VCPU_PMU_V3_CTRL 0
+#define KVM_ARM_VCPU_PMU_V3_IRQ 0
+#define KVM_ARM_VCPU_PMU_V3_INIT 1
+#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_DEV_ARM_VGIC_CTRL_INIT 0
/* KVM_IRQ_LINE irq field index values */
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index acea05e..1e0784e 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -308,6 +308,9 @@ int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
int ret;
switch (attr->group) {
+ case KVM_ARM_VCPU_TIMER_CTRL:
+ ret = kvm_arm_timer_set_attr(vcpu, attr);
+ break;
default:
ret = -ENXIO;
break;
@@ -322,6 +325,9 @@ int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
int ret;
switch (attr->group) {
+ case KVM_ARM_VCPU_TIMER_CTRL:
+ ret = kvm_arm_timer_get_attr(vcpu, attr);
+ break;
default:
ret = -ENXIO;
break;
@@ -336,6 +342,9 @@ int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
int ret;
switch (attr->group) {
+ case KVM_ARM_VCPU_TIMER_CTRL:
+ ret = kvm_arm_timer_has_attr(vcpu, attr);
+ break;
default:
ret = -ENXIO;
break;
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index cd6bea4..fc64518 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -226,6 +226,9 @@ struct kvm_arch_memory_slot {
#define KVM_ARM_VCPU_PMU_V3_CTRL 0
#define KVM_ARM_VCPU_PMU_V3_IRQ 0
#define KVM_ARM_VCPU_PMU_V3_INIT 1
+#define KVM_ARM_VCPU_TIMER_CTRL 1
+#define KVM_ARM_VCPU_TIMER_IRQ_VTIMER 0
+#define KVM_ARM_VCPU_TIMER_IRQ_PTIMER 1
/* 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 b37446a..5c7f657 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -390,6 +390,9 @@ int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
case KVM_ARM_VCPU_PMU_V3_CTRL:
ret = kvm_arm_pmu_v3_set_attr(vcpu, attr);
break;
+ case KVM_ARM_VCPU_TIMER_CTRL:
+ ret = kvm_arm_timer_set_attr(vcpu, attr);
+ break;
default:
ret = -ENXIO;
break;
@@ -407,6 +410,9 @@ int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
case KVM_ARM_VCPU_PMU_V3_CTRL:
ret = kvm_arm_pmu_v3_get_attr(vcpu, attr);
break;
+ case KVM_ARM_VCPU_TIMER_CTRL:
+ ret = kvm_arm_timer_get_attr(vcpu, attr);
+ break;
default:
ret = -ENXIO;
break;
@@ -424,6 +430,9 @@ int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
case KVM_ARM_VCPU_PMU_V3_CTRL:
ret = kvm_arm_pmu_v3_has_attr(vcpu, attr);
break;
+ case KVM_ARM_VCPU_TIMER_CTRL:
+ ret = kvm_arm_timer_has_attr(vcpu, attr);
+ break;
default:
ret = -ENXIO;
break;
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index f1c967a..f0053f8 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -68,6 +68,10 @@ void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu);
u64 kvm_arm_timer_get_reg(struct kvm_vcpu *, u64 regid);
int kvm_arm_timer_set_reg(struct kvm_vcpu *, u64 regid, u64 value);
+int kvm_arm_timer_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
+int kvm_arm_timer_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
+int kvm_arm_timer_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
+
bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx);
void kvm_timer_schedule(struct kvm_vcpu *vcpu);
void kvm_timer_unschedule(struct kvm_vcpu *vcpu);
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 6c5a064..d3d1dce 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -21,6 +21,7 @@
#include <linux/kvm_host.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
+#include <linux/uaccess.h>
#include <clocksource/arm_arch_timer.h>
#include <asm/arch_timer.h>
@@ -617,6 +618,28 @@ void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu)
kvm_vgic_unmap_phys_irq(vcpu, vtimer->irq.irq);
}
+static bool timer_irqs_are_valid(struct kvm *kvm)
+{
+ struct kvm_vcpu *vcpu;
+ int vtimer_irq, ptimer_irq;
+ int i;
+
+ vcpu = kvm_get_vcpu(kvm, 0);
+ vtimer_irq = vcpu_vtimer(vcpu)->irq.irq;
+ ptimer_irq = vcpu_ptimer(vcpu)->irq.irq;
+
+ if (vtimer_irq == ptimer_irq)
+ return false;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ if (vcpu_vtimer(vcpu)->irq.irq != vtimer_irq ||
+ vcpu_ptimer(vcpu)->irq.irq != ptimer_irq)
+ return false;
+ }
+
+ return true;
+}
+
int kvm_timer_enable(struct kvm_vcpu *vcpu)
{
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
@@ -636,6 +659,11 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
if (!vgic_initialized(vcpu->kvm))
return -ENODEV;
+ if (!timer_irqs_are_valid(vcpu->kvm)) {
+ kvm_debug("incorrectly configured timer irqs\n");
+ return -EINVAL;
+ }
+
/*
* Find the physical IRQ number corresponding to the host_vtimer_irq
*/
@@ -685,3 +713,79 @@ void kvm_timer_init_vhe(void)
val |= (CNTHCTL_EL1PCTEN << cnthctl_shift);
write_sysreg(val, cnthctl_el2);
}
+
+static void set_timer_irqs(struct kvm *kvm, int vtimer_irq, int ptimer_irq)
+{
+ struct kvm_vcpu *vcpu;
+ int i;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ vcpu_vtimer(vcpu)->irq.irq = vtimer_irq;
+ vcpu_ptimer(vcpu)->irq.irq = ptimer_irq;
+ }
+}
+
+int kvm_arm_timer_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+ int __user *uaddr = (int __user *)(long)attr->addr;
+ struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
+ struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
+ int irq;
+
+ if (!irqchip_in_kernel(vcpu->kvm))
+ return -EINVAL;
+
+ if (get_user(irq, uaddr))
+ return -EFAULT;
+
+ if (!(irq_is_ppi(irq)))
+ return -EINVAL;
+
+ if (vcpu->arch.timer_cpu.enabled)
+ return -EBUSY;
+
+ switch (attr->attr) {
+ case KVM_ARM_VCPU_TIMER_IRQ_VTIMER:
+ set_timer_irqs(vcpu->kvm, irq, ptimer->irq.irq);
+ break;
+ case KVM_ARM_VCPU_TIMER_IRQ_PTIMER:
+ set_timer_irqs(vcpu->kvm, vtimer->irq.irq, irq);
+ break;
+ default:
+ return -ENXIO;
+ }
+
+ return 0;
+}
+
+int kvm_arm_timer_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+ int __user *uaddr = (int __user *)(long)attr->addr;
+ struct arch_timer_context *timer;
+ int irq;
+
+ switch (attr->attr) {
+ case KVM_ARM_VCPU_TIMER_IRQ_VTIMER:
+ timer = vcpu_vtimer(vcpu);
+ break;
+ case KVM_ARM_VCPU_TIMER_IRQ_PTIMER:
+ timer = vcpu_ptimer(vcpu);
+ break;
+ default:
+ return -ENXIO;
+ }
+
+ irq = timer->irq.irq;
+ return put_user(irq, uaddr);
+}
+
+int kvm_arm_timer_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+ switch (attr->attr) {
+ case KVM_ARM_VCPU_TIMER_IRQ_VTIMER:
+ case KVM_ARM_VCPU_TIMER_IRQ_PTIMER:
+ return 0;
+ }
+
+ return -ENXIO;
+}
--
2.9.0
^ permalink raw reply related
* [PATCH v2] misc: sram-exec: Use aligned fncpy instead of memcpy
From: Russell King - ARM Linux @ 2017-05-03 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170410145247.6023-1-d-gerlach@ti.com>
On Mon, Apr 10, 2017 at 09:52:47AM -0500, Dave Gerlach wrote:
> Currently the sram-exec functionality, which allows allocation of
> executable memory and provides an API to move code to it, is only
> selected in configs for the ARM architecture. Based on commit
> 5756e9dd0de6 ("ARM: 6640/1: Thumb-2: Symbol manipulation macros for
> function body copying") simply copying a C function pointer address
> using memcpy without consideration of alignment and Thumb is unsafe on
> ARM platforms.
>
> The aforementioned patch introduces the fncpy macro which is a safe way
> to copy executable code on ARM platforms, so let's make use of that here
> rather than the unsafe plain memcpy that was previously used by
> sram_exec_copy. Now sram_exec_copy will move the code to "dst" and
> return an address that is guaranteed to be safely callable.
>
> In the future, architectures hoping to make use of the sram-exec
> functionality must define an fncpy macro just as ARM has done to
> guarantee or check for safe copying to executable memory before allowing
> the arch to select CONFIG_SRAM_EXEC.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Looks a lot saner, thanks. It's just a bit sad that we lose the type
checking.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>
> v1: http://www.spinics.net/lists/linux-omap/msg136517.html
>
> v2 changes: Return value of fncpy, as the returned address is the safely
> executable one, and add supporting docs in comments.
>
> drivers/misc/sram-exec.c | 27 ++++++++++++++++++++-------
> include/linux/sram.h | 8 ++++----
> 2 files changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/misc/sram-exec.c b/drivers/misc/sram-exec.c
> index ac522417c462..9d54e14e8360 100644
> --- a/drivers/misc/sram-exec.c
> +++ b/drivers/misc/sram-exec.c
> @@ -19,6 +19,7 @@
> #include <linux/sram.h>
>
> #include <asm/cacheflush.h>
> +#include <asm/fncpy.h>
>
> #include "sram.h"
>
> @@ -57,20 +58,32 @@ int sram_add_protect_exec(struct sram_partition *part)
> * @src: Source address for the data to copy
> * @size: Size of copy to perform, which starting from dst, must reside in pool
> *
> + * Return: Address for copied data that can safely be called through function
> + * pointer, or NULL if problem.
> + *
> * This helper function allows sram driver to act as central control location
> * of 'protect-exec' pools which are normal sram pools but are always set
> * read-only and executable except when copying data to them, at which point
> * they are set to read-write non-executable, to make sure no memory is
> * writeable and executable at the same time. This region must be page-aligned
> * and is checked during probe, otherwise page attribute manipulation would
> - * not be possible.
> + * not be possible. Care must be taken to only call the returned address as
> + * dst address is not guaranteed to be safely callable.
> + *
> + * NOTE: This function uses the fncpy macro to move code to the executable
> + * region. Some architectures have strict requirements for relocating
> + * executable code, so fncpy is a macro that must be defined by any arch
> + * making use of this functionality that guarantees a safe copy of exec
> + * data and returns a safe address that can be called as a C function
> + * pointer.
> */
> -int sram_exec_copy(struct gen_pool *pool, void *dst, void *src,
> - size_t size)
> +void *sram_exec_copy(struct gen_pool *pool, void *dst, void *src,
> + size_t size)
> {
> struct sram_partition *part = NULL, *p;
> unsigned long base;
> int pages;
> + void *dst_cpy;
>
> mutex_lock(&exec_pool_list_mutex);
> list_for_each_entry(p, &exec_pool_list, list) {
> @@ -80,10 +93,10 @@ int sram_exec_copy(struct gen_pool *pool, void *dst, void *src,
> mutex_unlock(&exec_pool_list_mutex);
>
> if (!part)
> - return -EINVAL;
> + return NULL;
>
> if (!addr_in_gen_pool(pool, (unsigned long)dst, size))
> - return -EINVAL;
> + return NULL;
>
> base = (unsigned long)part->base;
> pages = PAGE_ALIGN(size) / PAGE_SIZE;
> @@ -93,13 +106,13 @@ int sram_exec_copy(struct gen_pool *pool, void *dst, void *src,
> set_memory_nx((unsigned long)base, pages);
> set_memory_rw((unsigned long)base, pages);
>
> - memcpy(dst, src, size);
> + dst_cpy = fncpy(dst, src, size);
>
> set_memory_ro((unsigned long)base, pages);
> set_memory_x((unsigned long)base, pages);
>
> mutex_unlock(&part->lock);
>
> - return 0;
> + return dst_cpy;
> }
> EXPORT_SYMBOL_GPL(sram_exec_copy);
> diff --git a/include/linux/sram.h b/include/linux/sram.h
> index c97dcbe8ce25..4fb405fb0480 100644
> --- a/include/linux/sram.h
> +++ b/include/linux/sram.h
> @@ -16,12 +16,12 @@
> struct gen_pool;
>
> #ifdef CONFIG_SRAM_EXEC
> -int sram_exec_copy(struct gen_pool *pool, void *dst, void *src, size_t size);
> +void *sram_exec_copy(struct gen_pool *pool, void *dst, void *src, size_t size);
> #else
> -static inline int sram_exec_copy(struct gen_pool *pool, void *dst, void *src,
> - size_t size)
> +static inline void *sram_exec_copy(struct gen_pool *pool, void *dst, void *src,
> + size_t size)
> {
> - return -ENODEV;
> + return NULL;
> }
> #endif /* CONFIG_SRAM_EXEC */
> #endif /* __LINUX_SRAM_H__ */
> --
> 2.11.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* 答复: [PATCH 0/3] arm64: queued spinlocks and rw-locks
From: pan xinhui @ 2017-05-03 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503145141.4966-1-ynorov@caviumnetworks.com>
? 2017/5/3 22:51, Yury Norov ??:> The patch 3 adds implementation for queued-based locking on
> ARM64, and the option in kernel config to enable it. Patches
> 1 and 2 fix some mess in header files to apply patch 3 smoothly.
>
> Tested on QDF2400 with huge improvements with these patches on
> the torture tests, by Adam Wallis.
>
> Tested on ThunderX, by Andrew Pinski:
> 120 thread (30 core - 4 thread/core) CN99xx (single socket):
>
> benchmark Units qspinlocks vs ticket locks
> sched/messaging s 73.91%
> sched/pipe ops/s 104.18%
> futex/hash ops/s 103.87%
> futex/wake ms 71.04%
> futex/wake-parallel ms 93.88%
> futex/requeue ms 96.47%
> futex/lock-pi ops/s 118.33%
>
> Notice, there's the queued locks implementation for the Power PC introduced
> by Pan Xinhui. He largely tested it and also found significant performance
> gain. In arch part it is very similar to this patch though.
> https://lwn.net/Articles/701137/Hi, Yury
Glad to know you will join locking development :)
I have left IBM. However I still care about the queued-spinlock anyway.
> RFC: https://www.spinics.net/lists/arm-kernel/msg575575.htmlI notice you raised one question about the performance degradation in the acquisition of rw-lock for read on qemu.
This is strange indeed. I once enabled qrwlock on ppc too.
I paste your test reseults below. Is this a result of
qspinlock + qrwlock VS qspinlock + normal rwlock or
qspinlock + qrwlock VS normal spinlock + normal rwlock?
Before After
spin_lock-torture: 38957034 37076367 -4.83
rw_lock-torture W: 5369471 18971957 253.33
rw_lock-torture R: 6413179 3668160 -42.80
I am not sure how that should happen. I make one RFC patch below(not based on latest kernel), you could apply it to check if ther is any performance improvement.
The idea is that.
In queued_write_lock_slowpath(), we did not unlock the ->wait_lock.
Because the writer hold the rwlock, all readers are still waiting anyway.
And in queued_read_lock_slowpath(), calling rspin_until_writer_unlock() looks like introduce a little overhead, say, spinning at the rwlock.
But in the end, queued_read_lock_slowpath() is too heavy, compared with the normal rwlock. such result maybe is somehow reasonable?
diff --git a/include/asm-generic/qrwlock.h b/include/asm-generic/qrwlock.h
index 54a8e65..28ee01d 100644
--- a/include/asm-generic/qrwlock.h
+++ b/include/asm-generic/qrwlock.h
@@ -28,8 +28,9 @@
* Writer states & reader shift and bias
*/
#define _QW_WAITING 1 /* A writer is waiting */
-#define _QW_LOCKED 0xff /* A writer holds the lock */
-#define _QW_WMASK 0xff /* Writer mask */
+#define _QW_KICK 0x80 /* need unlock the spinlock*/
+#define _QW_LOCKED 0x7f /* A writer holds the lock */
+#define _QW_WMASK 0x7f /* Writer mask */
#define _QR_SHIFT 8 /* Reader count shift */
#define _QR_BIAS (1U << _QR_SHIFT)
@@ -139,7 +140,10 @@ static inline void queued_read_unlock(struct qrwlock *lock)
*/
static inline void queued_write_unlock(struct qrwlock *lock)
{
- smp_store_release((u8 *)&lock->cnts, 0);
+ u32 v = atomic_read(&lock->cnts) & (_QW_WMASK | _QW_KICK);
+ if (v & _QW_KICK)
+ arch_spin_unlock(&lock->wait_lock);
+ (void)atomic_sub_return_release(v, &lock->cnts);
}
/*
diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
index fec0823..1f0ea02 100644
--- a/kernel/locking/qrwlock.c
+++ b/kernel/locking/qrwlock.c
@@ -116,7 +116,7 @@ void queued_write_lock_slowpath(struct qrwlock *lock)
/* Try to acquire the lock directly if no reader is present */
if (!atomic_read(&lock->cnts) &&
- (atomic_cmpxchg_acquire(&lock->cnts, 0, _QW_LOCKED) == 0))
+ (atomic_cmpxchg_acquire(&lock->cnts, 0, _QW_LOCKED|_QW_KICK) == 0))
goto unlock;
/*
@@ -138,12 +138,13 @@ void queued_write_lock_slowpath(struct qrwlock *lock)
cnts = atomic_read(&lock->cnts);
if ((cnts == _QW_WAITING) &&
(atomic_cmpxchg_acquire(&lock->cnts, _QW_WAITING,
- _QW_LOCKED) == _QW_WAITING))
+ _QW_LOCKED|_QW_KICK) == _QW_WAITING))
break;
cpu_relax_lowlatency();
}
unlock:
- arch_spin_unlock(&lock->wait_lock);
+ return;
}
EXPORT_SYMBOL(queued_write_lock_slowpath);
--
2.4.11
thanks
xinhui
> v1:
> - queued_spin_unlock_wait() and queued_spin_is_locked() are
> re-implemented in arch part to add additional memory barriers;
> - queued locks are made optional, ticket locks are enabled by default.
>
> Jan Glauber (1):
> arm64/locking: qspinlocks and qrwlocks support
>
> Yury Norov (2):
> kernel/locking: #include <asm/spinlock.h> in qrwlock.c
> asm-generic: don't #include <linux/atomic.h> in qspinlock_types.h
>
> arch/arm64/Kconfig | 24 +++++++++++++++++++
> arch/arm64/include/asm/qrwlock.h | 7 ++++++
> arch/arm64/include/asm/qspinlock.h | 42 +++++++++++++++++++++++++++++++++
> arch/arm64/include/asm/spinlock.h | 12 ++++++++++
> arch/arm64/include/asm/spinlock_types.h | 14 ++++++++---
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/qspinlock.c | 34 ++++++++++++++++++++++++++
> include/asm-generic/qspinlock.h | 1 +
> include/asm-generic/qspinlock_types.h | 8 -------
> kernel/locking/qrwlock.c | 1 +
> 10 files changed, 133 insertions(+), 11 deletions(-)
> create mode 100644 arch/arm64/include/asm/qrwlock.h
> create mode 100644 arch/arm64/include/asm/qspinlock.h
> create mode 100644 arch/arm64/kernel/qspinlock.c
>
^ permalink raw reply related
* [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)
From: Russell King - ARM Linux @ 2017-05-03 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cedfd68d-d0fe-6fa8-2676-b61f3ddda652@gmail.com>
On Wed, Apr 26, 2017 at 06:43:54PM +0300, Ivaylo Dimitrov wrote:
> >+static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_format *fmt)
> >+{
> >+ long long avg_lum = 0;
> >+ int x, y;
> >+
> >+ buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 +
> >+ fmt->fmt.pix.width / 4;
> >+
> >+ for (y = 0; y < fmt->fmt.pix.height / 2; y++) {
> >+ for (x = 0; x < fmt->fmt.pix.width / 2; x++)
>
> That would take some time :). AIUI, we have NEON support in ARM kernels
> (CONFIG_KERNEL_MODE_NEON), I wonder if it makes sense (me) to convert the
> above loop to NEON-optimized when it comes to it? Are there any drawbacks in
> using NEON code in kernel?
Using neon without the VFP state saved and restored corrupts userspace's
FP state. So, you have to save the entire VFP state to use neon in kernel
mode. There are helper functions for this: kernel_neon_begin() and
kernel_neon_end().
You can't build C code with the compiler believing that neon is available
as the compiler could emit neon instructions in unprotected kernel code.
Note that kernel_neon_begin() is only allowed to be called outside
interrupt context and with preemption disabled.
Given that, do we really want to be walking over multi-megabytes of image
data in the kernel with preemption disabled - it sounds like a recipe for
a very sluggish system. I think this should (and can only sensibly be
done) in userspace.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: V7M: Set cacheid iff DminLine or IminLine is nonzero
From: Russell King - ARM Linux @ 2017-05-03 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c933cd2-bfaf-e7d3-b868-9d9955a1a105@arm.com>
On Tue, May 02, 2017 at 09:31:24AM +0100, Vladimir Murzin wrote:
> On 26/04/17 11:04, Vladimir Murzin wrote:
> > Cache support is optional feature in M-class cores, thus DminLine or
> > IminLine of Cache Type Register is zero if caches are not implemented,
> > but we check the whole CTR which has other features encoded there.
> > Let's be more precise and check for DminLine and IminLine of CTR
> > before we set cacheid.
> >
> > Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> > ---
> > arch/arm/kernel/setup.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index f4e5450..231a1d83 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -315,7 +315,7 @@ static void __init cacheid_init(void)
> > if (arch >= CPU_ARCH_ARMv6) {
> > unsigned int cachetype = read_cpuid_cachetype();
> >
> > - if ((arch == CPU_ARCH_ARMv7M) && !cachetype) {
> > + if ((arch == CPU_ARCH_ARMv7M) && !(cachetype & 0xf000f)) {
> > cacheid = 0;
> > } else if ((cachetype & (7 << 29)) == 4 << 29) {
> > /* ARMv7 register format */
> >
>
> Ok for patch tracker?
Not yet, I've been away and I've no time right now to evaluate this
change. I'm hopefully going to catch up with some email in the coming
days.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: Fix __show_regs output timestamps
From: Russell King - ARM Linux @ 2017-05-03 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61817479ac8c4c6c8be702d2e2136fddac1b1821.1493228290.git.joe@perches.com>
On Wed, Apr 26, 2017 at 10:39:49AM -0700, Joe Perches wrote:
> Multiple line formats are not preferred as the second and
> subsequent lines may not have timestamps.
>
> Lacking timestamps makes reading the output a bit difficult.
> This also makes arm/arm64 output more similar.
>
> Previous:
>
> [ 1514.093231] pc : [<bf79c304>] lr : [<bf79ced8>] psr: a00f0013
> sp : ecdd7e20 ip : 00000000 fp : ffffffff
>
> New:
>
> [ 1514.093231] pc : [<bf79c304>] lr : [<bf79ced8>] psr: a00f0013
> [ 1514.105316] sp : ecdd7e20 ip : 00000000 fp : ffffffff
>
> Signed-off-by: Joe Perches <joe@perches.com>
Hi Joe,
Could you put this in my patch system please, I'm unlikely to remember to
apply it otherwise if not already there (massive email backlog.)
Thanks.
> ---
> arch/arm/kernel/process.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 939e8b58c59d..151cece4a293 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -123,10 +123,10 @@ void __show_regs(struct pt_regs *regs)
>
> print_symbol("PC is at %s\n", instruction_pointer(regs));
> print_symbol("LR is at %s\n", regs->ARM_lr);
> - printk("pc : [<%08lx>] lr : [<%08lx>] psr: %08lx\n"
> - "sp : %08lx ip : %08lx fp : %08lx\n",
> - regs->ARM_pc, regs->ARM_lr, regs->ARM_cpsr,
> - regs->ARM_sp, regs->ARM_ip, regs->ARM_fp);
> + printk("pc : [<%08lx>] lr : [<%08lx>] psr: %08lx\n",
> + regs->ARM_pc, regs->ARM_lr, regs->ARM_cpsr);
> + printk("sp : %08lx ip : %08lx fp : %08lx\n",
> + regs->ARM_sp, regs->ARM_ip, regs->ARM_fp);
> printk("r10: %08lx r9 : %08lx r8 : %08lx\n",
> regs->ARM_r10, regs->ARM_r9,
> regs->ARM_r8);
> --
> 2.10.0.rc2.1.g053435c
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: Fix rd_size declaration
From: Russell King - ARM Linux @ 2017-05-03 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493239894.2632.15.camel@sandisk.com>
On Wed, Apr 26, 2017 at 08:51:35PM +0000, Bart Van Assche wrote:
> On Mon, 2017-04-17 at 16:10 -0700, Bart Van Assche wrote:
> > The global variable 'rd_size' is declared as 'int' in source file
> > arch/arm/kernel/atags_parse.c and as 'unsigned long' in
> > drivers/block/brd.c. Fix this inconsistency.
> > [ ... ]
>
> Hello Russell,
>
> Have I sent this patch to the right maintainer?
There were comments on the patch which seemed to be unresolved.
I, too, don't like the idea of a single-line header file. I'm also
wondering what the right solution here is - we're the only architecture
in the modern kernel that writes to rd_size, no one else does that.
I haven't been able to dig into the history to find out whether other
architectures used to, or what.
However, it would be nice if rd_size could go with some other related
declarations somewhere (if there are any.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
From: Marek Vasut @ 2017-05-03 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493834298.11226.40.camel@nxp.com>
On 05/03/2017 07:58 PM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
>> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
>>> On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
>>>> 2) It actually fixes a problem with the voltage rails such that the DVFS
>>>> works without leaving the system in unstable or dead state. You do
>>>> need the second part of my patch if you drop the OPP hackery, without
>>>> it the power framework cannot correctly configure the core voltages,
>>>> so the patch from Leonard makes things worse.
>>> No, I think there is a misunderstanding here. The second part of your
>>> patch will cause cpufreq poking at LDOs to indirectly adjust the input
>>> from the PMIC to the minimum required (this is LDO target +
>>> min_dropout_uv). Without it by default VDD_ARM_SOC_IN will remain fixed
>>> as 1375mV from boot.
>
>> Who sets / guarantees that default value for ARM and SOC rails ?
>
> I think it's from the PMIC hardware itself (but maybe uboot plays with
> it). VDD_ARM_SOC_IN on this board is tied to SW1AB from MMPF0200:
>
> http://www.nxp.com/assets/documents/data/en/data-sheets/MMPF0200.pdf
>
> It seems reasonable to rely on such voltages set externally.
Isn't it an established rule that Linux should not depend on bootloader
settings ? Or did that change ?
>> With the OPP override in place, there's at least the guarantee that both
>> rails will have the same voltage requirement. If you remove the OPP
>> override without modeling the actual regulator wiring, the guarantee is
>> gone.
>
> The imx6sx chip has internal LDO_ARM and LDO_SOC regulators which can
> generate separate voltages for arm/soc. The fact that these regulators
> share the same supply is only an issue when they are set in bypass
> mode.
>
> However the boot issues happen on REV C but apparently not REV B of the
> board. I don't have a good explanation for this so maybe I am missing
> something.
Well the regulator(s) cannot be correctly configured if the kernel
doesn't have the correct power distribution described in the DT .
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] ARM: Fix rd_size declaration
From: Bart Van Assche @ 2017-05-03 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503192541.GE22219@n2100.armlinux.org.uk>
On Wed, 2017-05-03 at 20:25 +0100, Russell King - ARM Linux wrote:
> There were comments on the patch which seemed to be unresolved.
Do you mean the header guard? That's easy to resolve.
> However, it would be nice if rd_size could go with some other related
> declarations somewhere (if there are any.)
Sorry but I don't know about any other declarations that should be moved
into a brd header file.
Bart.
^ permalink raw reply
* [PATCH] ARM: Fix __show_regs output timestamps
From: Joe Perches @ 2017-05-03 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503192310.GD22219@n2100.armlinux.org.uk>
On Wed, 2017-05-03 at 20:23 +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 26, 2017 at 10:39:49AM -0700, Joe Perches wrote:
> > Multiple line formats are not preferred as the second and
> > subsequent lines may not have timestamps.
> >
> > Lacking timestamps makes reading the output a bit difficult.
> > This also makes arm/arm64 output more similar.
> >
> > Previous:
> >
> > [ 1514.093231] pc : [<bf79c304>] lr : [<bf79ced8>] psr: a00f0013
> > sp : ecdd7e20 ip : 00000000 fp : ffffffff
> >
> > New:
> >
> > [ 1514.093231] pc : [<bf79c304>] lr : [<bf79ced8>] psr: a00f0013
> > [ 1514.105316] sp : ecdd7e20 ip : 00000000 fp : ffffffff
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
> Hi Joe,
>
> Could you put this in my patch system please, I'm unlikely to remember to
> apply it otherwise if not already there (massive email backlog.)
>
> Thanks.
Rehi Russell.
Done,?and I had to lookup your "my patch system", even
though it was in your trailer, the email address of the
system wasn't listed until bullet point 8.
If you've the time to ask me to do this, it seems likely
you could have forwarded the original email to your patch
system yourself instead.
Also "patches at armlinux.org.uk" isn't mentioned at all in
either the documentation or MAINTAINERS. Should it be?
btw: http://www.armlinux.org.uk/developer/patches/info.php
has many outdated references like:
Once the 2.7 kernel opens, support for new features in the 2.6
kernels will not be accepted unless similar support is also available
for the 2.7 kernel.
^ permalink raw reply
* [PATCH] ARM: Fix __show_regs output timestamps
From: Joe Perches @ 2017-05-03 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503192310.GD22219@n2100.armlinux.org.uk>
On Wed, 2017-05-03 at 20:23 +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 26, 2017 at 10:39:49AM -0700, Joe Perches wrote:
> > Multiple line formats are not preferred as the second and
> > subsequent lines may not have timestamps.
> >
> > Lacking timestamps makes reading the output a bit difficult.
> > This also makes arm/arm64 output more similar.
> >
> > Previous:
> >
> > [ 1514.093231] pc : [<bf79c304>] lr : [<bf79ced8>] psr: a00f0013
> > sp : ecdd7e20 ip : 00000000 fp : ffffffff
> >
> > New:
> >
> > [ 1514.093231] pc : [<bf79c304>] lr : [<bf79ced8>] psr: a00f0013
> > [ 1514.105316] sp : ecdd7e20 ip : 00000000 fp : ffffffff
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
> Hi Joe,
>
> Could you put this in my patch system please, I'm unlikely to remember to
> apply it otherwise if not already there (massive email backlog.)
>
> Thanks.
Your patch system bounced my perfectly formatted patch
because your system wants totally unnecessary additional
information specific to your workflow.
No thanks, I don't need the additional work just to
please your system and neither should anyone else.
^ permalink raw reply
* [PATCH] ARM: Fix rd_size declaration
From: Bart Van Assche @ 2017-05-03 19:46 UTC (permalink / raw)
To: linux-arm-kernel
The global variable 'rd_size' is declared as 'int' in source file
arch/arm/kernel/atags_parse.c and as 'unsigned long' in
drivers/block/brd.c. Fix this inconsistency. Additionally, remove
the declarations of rd_image_start, rd_prompt and rd_doload from
parse_tag_ramdisk() since these duplicate existing declarations
in <linux/initrd.h>.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Jan Kara <jack@suse.cz>
Cc: <yanaijie@huawei.com>
Cc: <zhaohongjiang@huawei.com>
Cc: <miaoxie@huawei.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-block at vger.kernel.org
---
arch/arm/kernel/atags_parse.c | 3 +--
drivers/block/brd.c | 1 +
include/linux/initrd.h | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
index 68c6ae0b9e4c..98fbfd235ac8 100644
--- a/arch/arm/kernel/atags_parse.c
+++ b/arch/arm/kernel/atags_parse.c
@@ -18,6 +18,7 @@
*/
#include <linux/init.h>
+#include <linux/initrd.h>
#include <linux/kernel.h>
#include <linux/fs.h>
#include <linux/root_dev.h>
@@ -91,8 +92,6 @@ __tagtable(ATAG_VIDEOTEXT, parse_tag_videotext);
#ifdef CONFIG_BLK_DEV_RAM
static int __init parse_tag_ramdisk(const struct tag *tag)
{
- extern int rd_size, rd_image_start, rd_prompt, rd_doload;
-
rd_image_start = tag->u.ramdisk.start;
rd_doload = (tag->u.ramdisk.flags & 1) == 0;
rd_prompt = (tag->u.ramdisk.flags & 2) == 0;
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 3adc32a3153b..30a45080a9b4 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -9,6 +9,7 @@
*/
#include <linux/init.h>
+#include <linux/initrd.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/major.h>
diff --git a/include/linux/initrd.h b/include/linux/initrd.h
index 55289d261b4f..bc67b767f9ce 100644
--- a/include/linux/initrd.h
+++ b/include/linux/initrd.h
@@ -10,6 +10,9 @@ extern int rd_prompt;
/* starting block # of image */
extern int rd_image_start;
+/* size of a single RAM disk */
+extern unsigned long rd_size;
+
/* 1 if it is not an error if initrd_start < memory_start */
extern int initrd_below_start_ok;
--
2.12.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox