* linux-next: manual merge of the pm tree with the arm-soc tree
From: Dave Gerlach @ 2017-04-24 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3dfaceb-41ba-b13d-f47e-a279c3e2f6b9@oracle.com>
On 04/21/2017 04:54 PM, Santosh Shilimkar wrote:
> +Dave,
>
> On 4/21/2017 2:44 PM, Arnd Bergmann wrote:
>> On Fri, Apr 21, 2017 at 11:02 PM, santosh.shilimkar at oracle.com
>> <santosh.shilimkar@oracle.com> wrote:
>>> On 4/21/17 2:31 AM, Arnd Bergmann wrote:
>
> [...]
>
>>>> arm-soc/next/drivers:
>>>> ae3874cc931b ARM: keystone: Drop PM domain support for k2g
>>>> 52835d59fc6c soc: ti: Add ti_sci_pm_domains driver
>>>> 7cc119f29b19 dt-bindings: Add TI SCI PM Domains
>>>> 213ec7fed302 PM / Domains: Do not check if simple providers have phandle
>>>> cells
>>>> a5ea7a0fcbd7 PM / Domains: Add generic data pointer to genpd data struct
>>>>
>>> Above are the correct git object for which I sent pull request for.
>>
>> Ok, good, thanks for checking! They are however the commits that
>> contain the silly https://urldefense.proofpoint.com URLs. Can you
>> send a follow-up patch to fix these and use the regular
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ti.org&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=XBn1JQGPwR8CsE7xpP3wPlG6DQU7qw8ym65xieNZ4hY&m=vFHOEb7p2FxbH00YRQq4WnRiu2BKHADn0gl6e6DoNFQ&s=7mfiIp2Ywy9_ppWKjEGlrswiKRndv8_I7zGVF9uyT0w&e=
>>
>> URL that is in linux-next?
>>
> Dave,
> Any reason you changed these URLs in last version ?
> Can you please fixup these URLs to along with DT defines.
I didn't change any of the URLs in the patches, I am not sure what those URLs
are. In the patches I sent the URLs are fine, and I see them normal on patchwork
too: https://patchwork.kernel.org/patch/9660785/
Is there something that automatically changes those? I don't want to send
another patch for it to just get mangled again.
Regards,
Dave
>
> Regards,
> Santosh
^ permalink raw reply
* [PATCH 3/3 v2] xen: Implement EFI reset_system callback
From: Julien Grall @ 2017-04-24 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424175839.5262-1-julien.grall@arm.com>
When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack
trace [1].
This is happening because when EFI runtimes are enabled, the reset code
(see machine_restart) will first try to use EFI restart method.
However, the EFI restart code is expecting the reset_system callback to
be always set. This is not the case for Xen and will lead to crash.
The EFI restart helper is used in multiple places and some of them don't
not have fallback (see machine_power_off). So implement reset_system
callback as a call to xen_reboot when using EFI Xen.
[ 36.999270] reboot: Restarting system
[ 37.002921] Internal error: Attempting to execute userspace memory: 86000004 [#1] PREEMPT SMP
[ 37.011460] Modules linked in:
[ 37.014598] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.11.0-rc1-00003-g1e248b60a39b-dirty #506
[ 37.023903] Hardware name: (null) (DT)
[ 37.027734] task: ffff800902068000 task.stack: ffff800902064000
[ 37.033739] PC is at 0x0
[ 37.036359] LR is at efi_reboot+0x94/0xd0
[ 37.040438] pc : [<0000000000000000>] lr : [<ffff00000880f2c4>] pstate: 404001c5
[ 37.047920] sp : ffff800902067cf0
[ 37.051314] x29: ffff800902067cf0 x28: ffff800902068000
[ 37.056709] x27: ffff000008992000 x26: 000000000000008e
[ 37.062104] x25: 0000000000000123 x24: 0000000000000015
[ 37.067499] x23: 0000000000000000 x22: ffff000008e6e250
[ 37.072894] x21: ffff000008e6e000 x20: 0000000000000000
[ 37.078289] x19: ffff000008e5d4c8 x18: 0000000000000010
[ 37.083684] x17: 0000ffffa7c27470 x16: 00000000deadbeef
[ 37.089079] x15: 0000000000000006 x14: ffff000088f42bef
[ 37.094474] x13: ffff000008f42bfd x12: ffff000008e706c0
[ 37.099870] x11: ffff000008e70000 x10: 0000000005f5e0ff
[ 37.105265] x9 : ffff800902067a50 x8 : 6974726174736552
[ 37.110660] x7 : ffff000008cc6fb8 x6 : ffff000008cc6fb0
[ 37.116055] x5 : ffff000008c97dd8 x4 : 0000000000000000
[ 37.121453] x3 : 0000000000000000 x2 : 0000000000000000
[ 37.126845] x1 : 0000000000000000 x0 : 0000000000000000
[ 37.132239]
[ 37.133808] Process systemd-shutdow (pid: 1, stack limit = 0xffff800902064000)
[ 37.141118] Stack: (0xffff800902067cf0 to 0xffff800902068000)
[ 37.146949] 7ce0: ffff800902067d40 ffff000008085334
[ 37.154869] 7d00: 0000000000000000 ffff000008f3b000 ffff800902067d40 ffff0000080852e0
[ 37.162787] 7d20: ffff000008cc6fb0 ffff000008cc6fb8 ffff000008c7f580 ffff000008c97dd8
[ 37.170706] 7d40: ffff800902067d60 ffff0000080e2c2c 0000000000000000 0000000001234567
[ 37.178624] 7d60: ffff800902067d80 ffff0000080e2ee8 0000000000000000 ffff0000080e2df4
[ 37.186544] 7d80: 0000000000000000 ffff0000080830f0 0000000000000000 00008008ff1c1000
[ 37.194462] 7da0: ffffffffffffffff 0000ffffa7c4b1cc 0000000000000000 0000000000000024
[ 37.202380] 7dc0: ffff800902067dd0 0000000000000005 0000fffff24743c8 0000000000000004
[ 37.210299] 7de0: 0000fffff2475f03 0000000000000010 0000fffff2474418 0000000000000005
[ 37.218218] 7e00: 0000fffff2474578 000000000000000a 0000aaaad6b722c0 0000000000000001
[ 37.226136] 7e20: 0000000000000123 0000000000000038 ffff800902067e50 ffff0000081e7294
[ 37.234055] 7e40: ffff800902067e60 ffff0000081e935c ffff800902067e60 ffff0000081e9388
[ 37.241973] 7e60: ffff800902067eb0 ffff0000081ea388 0000000000000000 00008008ff1c1000
[ 37.249892] 7e80: ffffffffffffffff 0000ffffa7c4a79c 0000000000000000 ffff000000020000
[ 37.257810] 7ea0: 0000010000000004 0000000000000000 0000000000000000 ffff0000080830f0
[ 37.265729] 7ec0: fffffffffee1dead 0000000028121969 0000000001234567 0000000000000000
[ 37.273651] 7ee0: ffffffffffffffff 8080000000800000 0000800000008080 feffa9a9d4ff2d66
[ 37.281567] 7f00: 000000000000008e feffa9a9d5b60e0f 7f7fffffffff7f7f 0101010101010101
[ 37.289485] 7f20: 0000000000000010 0000000000000008 000000000000003a 0000ffffa7ccf588
[ 37.297404] 7f40: 0000aaaad6b87d00 0000ffffa7c4b1b0 0000fffff2474be0 0000aaaad6b88000
[ 37.305326] 7f60: 0000fffff2474fb0 0000000001234567 0000000000000000 0000000000000000
[ 37.313240] 7f80: 0000000000000000 0000000000000001 0000aaaad6b70d4d 0000000000000000
[ 37.321159] 7fa0: 0000000000000001 0000fffff2474ea0 0000aaaad6b5e2e0 0000fffff2474e80
[ 37.329078] 7fc0: 0000ffffa7c4b1cc 0000000000000000 fffffffffee1dead 000000000000008e
[ 37.336997] 7fe0: 0000000000000000 0000000000000000 9ce839cffee77eab fafdbf9f7ed57f2f
[ 37.344911] Call trace:
[ 37.347437] Exception stack(0xffff800902067b20 to 0xffff800902067c50)
[ 37.353970] 7b20: ffff000008e5d4c8 0001000000000000 0000000080f82000 0000000000000000
[ 37.361883] 7b40: ffff800902067b60 ffff000008e17000 ffff000008f44c68 00000001081081b4
[ 37.369802] 7b60: ffff800902067bf0 ffff000008108478 0000000000000000 ffff000008c235b0
[ 37.377721] 7b80: ffff800902067ce0 0000000000000000 0000000000000000 0000000000000015
[ 37.385643] 7ba0: 0000000000000123 000000000000008e ffff000008992000 ffff800902068000
[ 37.393557] 7bc0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 37.401477] 7be0: 0000000000000000 ffff000008c97dd8 ffff000008cc6fb0 ffff000008cc6fb8
[ 37.409396] 7c00: 6974726174736552 ffff800902067a50 0000000005f5e0ff ffff000008e70000
[ 37.417318] 7c20: ffff000008e706c0 ffff000008f42bfd ffff000088f42bef 0000000000000006
[ 37.425234] 7c40: 00000000deadbeef 0000ffffa7c27470
[ 37.430190] [< (null)>] (null)
[ 37.434982] [<ffff000008085334>] machine_restart+0x6c/0x70
[ 37.440550] [<ffff0000080e2c2c>] kernel_restart+0x6c/0x78
[ 37.446030] [<ffff0000080e2ee8>] SyS_reboot+0x130/0x228
[ 37.451337] [<ffff0000080830f0>] el0_svc_naked+0x24/0x28
[ 37.456737] Code: bad PC value
[ 37.459891] ---[ end trace 76e2fc17e050aecd ]---
Signed-off-by: Julien Grall <julien.grall@arm.com>
--
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86 at kernel.org
The x86 code has theoritically a similar issue, altought EFI does not
seem to be the preferred method. I have only built test it on x86.
This should also probably be fixed in stable tree.
Changes in v2:
- Implement xen_efi_reset_system using xen_reboot
- Move xen_efi_reset_system in drivers/xen/efi.c
---
arch/arm/xen/efi.c | 2 +-
arch/x86/xen/efi.c | 2 +-
drivers/xen/efi.c | 18 ++++++++++++++++++
include/xen/xen-ops.h | 3 +++
4 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
index 16db419f9e90..b4d78959cadf 100644
--- a/arch/arm/xen/efi.c
+++ b/arch/arm/xen/efi.c
@@ -35,6 +35,6 @@ void __init xen_efi_runtime_setup(void)
efi.update_capsule = xen_efi_update_capsule;
efi.query_capsule_caps = xen_efi_query_capsule_caps;
efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
- efi.reset_system = NULL; /* Functionality provided by Xen. */
+ efi.reset_system = xen_efi_reset_system;
}
EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 3be012115853..30bb2e80cfe7 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -81,7 +81,7 @@ static const struct efi efi_xen __initconst = {
.update_capsule = xen_efi_update_capsule,
.query_capsule_caps = xen_efi_query_capsule_caps,
.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
- .reset_system = NULL, /* Functionality provided by Xen. */
+ .reset_system = xen_efi_reset_system,
.set_virtual_address_map = NULL, /* Not used under Xen. */
.flags = 0 /* Initialized later. */
};
diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
index 22f71ffd3406..9243a9051078 100644
--- a/drivers/xen/efi.c
+++ b/drivers/xen/efi.c
@@ -26,6 +26,7 @@
#include <xen/interface/xen.h>
#include <xen/interface/platform.h>
#include <xen/xen.h>
+#include <xen/xen-ops.h>
#include <asm/page.h>
@@ -263,3 +264,20 @@ efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
return efi_data(op).status;
}
EXPORT_SYMBOL_GPL(xen_efi_query_capsule_caps);
+
+void xen_efi_reset_system(int reset_type, efi_status_t status,
+ unsigned long data_size, efi_char16_t *data)
+{
+ switch (reset_type) {
+ case EFI_RESET_COLD:
+ case EFI_RESET_WARM:
+ xen_reboot(SHUTDOWN_reboot);
+ break;
+ case EFI_RESET_SHUTDOWN:
+ xen_reboot(SHUTDOWN_poweroff);
+ break;
+ default:
+ BUG();
+ }
+}
+EXPORT_SYMBOL_GPL(xen_efi_reset_system);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index fc5ddb472f86..197bb4866327 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -122,6 +122,9 @@ efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
unsigned long count, u64 *max_size,
int *reset_type);
+void xen_efi_reset_system(int reset_type, efi_status_t status,
+ unsigned long data_size, efi_char16_t *data);
+
#ifdef CONFIG_PREEMPT
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3 v2] arm/xen: Consolidate calls to shutdown hypercall in a single helper
From: Julien Grall @ 2017-04-24 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424175839.5262-1-julien.grall@arm.com>
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
Changes in v2:
- Patch added
---
arch/arm/xen/enlighten.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 81e3217b12d3..ba7f4c8f5c3e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -191,20 +191,24 @@ static int xen_dying_cpu(unsigned int cpu)
return 0;
}
-static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
+void xen_reboot(int reason)
{
- struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
+ struct sched_shutdown r = { .reason = reason };
int rc;
+
rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
BUG_ON(rc);
}
+static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
+{
+ xen_reboot(SHUTDOWN_reboot);
+}
+
+
static void xen_power_off(void)
{
- struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
- int rc;
- rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
- BUG_ON(rc);
+ xen_reboot(SHUTDOWN_poweroff);
}
static irqreturn_t xen_arm_callback(int irq, void *arg)
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3 v2] xen: Export xen_reboot
From: Julien Grall @ 2017-04-24 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424175839.5262-1-julien.grall@arm.com>
The helper xen_reboot will be called by the EFI code in a later patch.
Note that the ARM version does not yet exist and will be added in a
later patch too.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86 at kernel.org
Changes in v2:
- Patch added
---
arch/x86/xen/enlighten.c | 2 +-
include/xen/xen-ops.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index ec1d5c46e58f..563f2d963a04 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1294,7 +1294,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
.end_context_switch = xen_end_context_switch,
};
-static void xen_reboot(int reason)
+void xen_reboot(int reason)
{
struct sched_shutdown r = { .reason = reason };
int cpu;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index b5486e648607..fc5ddb472f86 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -22,6 +22,8 @@ void xen_timer_resume(void);
void xen_arch_resume(void);
void xen_arch_suspend(void);
+void xen_reboot(int reason);
+
void xen_resume_notifier_register(struct notifier_block *nb);
void xen_resume_notifier_unregister(struct notifier_block *nb);
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3 v2] xen: Implement EFI reset_system callback
From: Julien Grall @ 2017-04-24 17:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This small patch series implements EFI reset_system callback when using EFI
Xen. Without this, it will not be possible to reboot/power off ARM64 DOM0
when using ACPI.
Cheers,
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Julien Grall (3):
xen: Export xen_reboot
arm/xen: Consolidate calls to shutdown hypercall in a single helper
xen: Implement EFI reset_system callback
arch/arm/xen/efi.c | 2 +-
arch/arm/xen/enlighten.c | 16 ++++++++++------
arch/x86/xen/efi.c | 2 +-
arch/x86/xen/enlighten.c | 2 +-
drivers/xen/efi.c | 18 ++++++++++++++++++
include/xen/xen-ops.h | 5 +++++
6 files changed, 36 insertions(+), 9 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH] arm64: fix the overlap between the kernel image and vmalloc address
From: Ard Biesheuvel @ 2017-04-24 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ffd0a3c5-5d89-4bbd-9995-c545bccaa8f6@redhat.com>
On 24 April 2017 at 18:52, Laura Abbott <labbott@redhat.com> wrote:
> On 04/24/2017 08:51 AM, Mark Rutland wrote:
>> On Mon, Apr 24, 2017 at 09:28:48PM +0800, zhong jiang wrote:
>>> On 2017/4/24 18:44, Mark Rutland wrote:
>>>> So the issue is that we have the callchain below for a kernel image
>>>> address:
>>>>
>>>> read_kcore()
>>>> ->is_vmalloc_or_module_addr() // returns true
>>>> ->vread()
>>>> -->aligned_vread()
>>>> --->vmalloc_to_page()
>>>>
>>>> In is_vmalloc{,or_module}_addr() we just check the addr against
>>>> VMALLOC_START and VMALLOC_END, so they will return true for a kernel
>>>> image address.
>>>>
>>>> Then, we call vmalloc_to_page(). While this only handles mappings made
>>>> at page granularity, the kernel image mapping may have used sections. So
>>>> this tries a bogus walk to the pte level.
>>
>>>> Should we special-case kernel image handling, e.g. with new
>>>> is_kernel_image_addr() / kernel_image_to_page() helpers?
>>
>>> yes , it seems to the best way to implents it without performance back.
>>
>>> The following patch is the implment. Any thought?
>>>
>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>>
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index b84615b..851ac35 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -475,6 +475,15 @@ static inline bool is_vmalloc_addr(const void *x)
>>> return false;
>>> #endif
>>> }
>>> +
>>> +static inline bool is_kernel_image_addr(const void *x)
>>> +{
>>> + unsigned long addr = (unsigned long)x;
>>> +
>>> + return addr >= (unsigned long)_stext && addr < (unsigned long)_end;
>>> +
>>> +}
>>> +
>>> #ifdef CONFIG_MMU
>>> extern int is_vmalloc_or_module_addr(const void *x);
>>> #else
>>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>>> index 3ca82d4..9a9ef65 100644
>>> --- a/mm/vmalloc.c
>>> +++ b/mm/vmalloc.c
>>> @@ -229,6 +229,42 @@ int is_vmalloc_or_module_addr(const void *x)
>>> return is_vmalloc_addr(x);
>>> }
>>>
>>> +static struct page *kernel_image_to_page(const void *kernel_addr, pgd_t *pgd)
>>> +{
>>> + unsigned long addr = (unsigned long)kernel_addr;
>>> + struct page *page = NULL;
>>> + pud_t *pud;
>>> + pmd_t *pmd;
>>> + pte_t *pte;
>>> +
>>> + if (pgd_none(*pgd))
>>> + goto out;
>>> +
>>> + pud = pud_offset(pgd, addr);
>>> + if (pud_none(*pud))
>>> + goto out;
>>> +
>>> + if (pud_sect(*pud))
>>> + return pud_page(*pud);
>>
>> The *_sect() helpers are arch-specific, so we cannot use them in generic
>> code. This would need to be architecture-specific.
>>
>> Secondly, this will return head page of the section regardless of which
>> page in the section the address corresponds to
>>
>>> +
>>> + pmd = pmd_offset(*pmd, addr);
>>> + if (pmd_none(*pmd))
>>> + goto out;
>>> +
>>> + if (pmd_sect(*pmd))
>>> + return pmd_page(*pmd);
>>
>> Likewise on both counts.
>>
>>> +
>>> + pte = pte_offset_kernel(pmd, addr);
>>> + if (pte_none(*pte))
>>> + goto out;
>>> +
>>> + page = pte_page(*pte);
>>> +
>>> +out:
>>> + return page;
>>> +
>>> +}
>>
>> Given we know what the address should map to, I don't think we need to
>> walk the page tables here. I think this can be:
>>
>> static struct page *kernel_image_to_page(const void *addr)
>> {
>> return virt_to_page(lm_alias(vmalloc_addr));
>> }
>>
>>> +
>>> /*
>>> * Walk a vmap address to the struct page it maps.
>>> */
>>> @@ -244,6 +280,9 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>>> */
>>> VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
>>>
>>> + if (is_kernel_image_addr(vmalloc_addr))
>>> + return kernel_image_to_page(vmalloc_addr, pgd);
>>
>> It's not clear to me that this is the right place for this to live.
>>
>> It might be best to code the kernel image logic directly in kcore (and
>> kmem), assuming everyone's OK with that approach.
>>
>
> That will fix kcore and kmem but this will show up in other places too.
> We've gone through and made sure that virt_addr_valid returns
> true if and only if virt_to_page returns a valid address. I don't know
> if we can make as strong a claim about is_vmalloc_addr and
> vmalloc_to_page in all cases but is_vmalloc_addr should not return true
> for the kernel image. That would at least let kcore fall back to
> kern_addr_valid which should correctly handle the kernel image.
> The suggestion to move the kernel image out of VMALLOC_START/VMALLOC_END
> seems like the best approach although I haven't tried a prototype
> at all.
>
Moving the kernel into the vmalloc region was kind of the point, for
KASLR. Undoing that means either disabling KASLR, or splitting the
vmalloc region into a KASLR region only for the kernel, and a vmalloc
region like we had when vmlinux lived in the linear region.
In general, I think we should be able to deal with different kinds of
mappings with different granularity in the vmalloc region. If
necessary, we could introduce a VM_xxx flag for the kernel to
distinguish such regions from ordinary VM_MAP regions.
^ permalink raw reply
* [PATCH V15 04/11] efi: parse ARM processor error
From: Borislav Petkov @ 2017-04-24 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e54c9893-446f-9e77-b78b-2548d394719b@codeaurora.org>
On Fri, Apr 21, 2017 at 12:22:09PM -0600, Baicar, Tyler wrote:
> I guess it's not really needed. It just may be useful considering there can
> be numerous error info structures, numerous context info structures, and a
> variable length vendor information section. I can move this print to only in
> the length check failure cases.
And? Why does the user care?
I mean, it is good for debugging when you wanna see you're parsing the
error info data properly but otherwise it doesn't improve the error
reporting one bit.
> Because these are part of the error information structure. I wouldn't think
> FW would populate error information structures that are different versions
> in the same processor error, but it could be possible from the spec (at
> least once there are different versions of the table).
Same argument as above.
> There is an error information 64 bit value in the ARM processor error
> information structure. (UEFI spec 2.6 table 261)
So that's IP-dependent and explained in the following tables. Any plans
on decoding that too?
> Why's that? Dumping this vendor specific error information is similar to the
> unrecognized CPER section reporting which is also meant for vendor specific
> information https://lkml.org/lkml/2017/4/18/751
And how do those naked bytes help the user understand the error happening?
Even in your example you have:
[ 140.739210] {1}[Hardware Error]: 00000000: 4d415201 4d492031 453a4d45 435f4343 .RAM1 IMEM:ECC_C
[ 140.739214] {1}[Hardware Error]: 00000010: 53515f45 44525f42 00000000 00000000 E_QSB_RD........
Which looks like some correctable ECC DRAM error and is actually begging
to be decoded in a human-readable form. So let's do that completely and
not dump partially decoded information.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH] arm64: fix the overlap between the kernel image and vmalloc address
From: Laura Abbott @ 2017-04-24 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424155125.GA5972@leverpostej>
On 04/24/2017 08:51 AM, Mark Rutland wrote:
> On Mon, Apr 24, 2017 at 09:28:48PM +0800, zhong jiang wrote:
>> On 2017/4/24 18:44, Mark Rutland wrote:
>>> So the issue is that we have the callchain below for a kernel image
>>> address:
>>>
>>> read_kcore()
>>> ->is_vmalloc_or_module_addr() // returns true
>>> ->vread()
>>> -->aligned_vread()
>>> --->vmalloc_to_page()
>>>
>>> In is_vmalloc{,or_module}_addr() we just check the addr against
>>> VMALLOC_START and VMALLOC_END, so they will return true for a kernel
>>> image address.
>>>
>>> Then, we call vmalloc_to_page(). While this only handles mappings made
>>> at page granularity, the kernel image mapping may have used sections. So
>>> this tries a bogus walk to the pte level.
>
>>> Should we special-case kernel image handling, e.g. with new
>>> is_kernel_image_addr() / kernel_image_to_page() helpers?
>
>> yes , it seems to the best way to implents it without performance back.
>
>> The following patch is the implment. Any thought?
>>
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index b84615b..851ac35 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -475,6 +475,15 @@ static inline bool is_vmalloc_addr(const void *x)
>> return false;
>> #endif
>> }
>> +
>> +static inline bool is_kernel_image_addr(const void *x)
>> +{
>> + unsigned long addr = (unsigned long)x;
>> +
>> + return addr >= (unsigned long)_stext && addr < (unsigned long)_end;
>> +
>> +}
>> +
>> #ifdef CONFIG_MMU
>> extern int is_vmalloc_or_module_addr(const void *x);
>> #else
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index 3ca82d4..9a9ef65 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -229,6 +229,42 @@ int is_vmalloc_or_module_addr(const void *x)
>> return is_vmalloc_addr(x);
>> }
>>
>> +static struct page *kernel_image_to_page(const void *kernel_addr, pgd_t *pgd)
>> +{
>> + unsigned long addr = (unsigned long)kernel_addr;
>> + struct page *page = NULL;
>> + pud_t *pud;
>> + pmd_t *pmd;
>> + pte_t *pte;
>> +
>> + if (pgd_none(*pgd))
>> + goto out;
>> +
>> + pud = pud_offset(pgd, addr);
>> + if (pud_none(*pud))
>> + goto out;
>> +
>> + if (pud_sect(*pud))
>> + return pud_page(*pud);
>
> The *_sect() helpers are arch-specific, so we cannot use them in generic
> code. This would need to be architecture-specific.
>
> Secondly, this will return head page of the section regardless of which
> page in the section the address corresponds to
>
>> +
>> + pmd = pmd_offset(*pmd, addr);
>> + if (pmd_none(*pmd))
>> + goto out;
>> +
>> + if (pmd_sect(*pmd))
>> + return pmd_page(*pmd);
>
> Likewise on both counts.
>
>> +
>> + pte = pte_offset_kernel(pmd, addr);
>> + if (pte_none(*pte))
>> + goto out;
>> +
>> + page = pte_page(*pte);
>> +
>> +out:
>> + return page;
>> +
>> +}
>
> Given we know what the address should map to, I don't think we need to
> walk the page tables here. I think this can be:
>
> static struct page *kernel_image_to_page(const void *addr)
> {
> return virt_to_page(lm_alias(vmalloc_addr));
> }
>
>> +
>> /*
>> * Walk a vmap address to the struct page it maps.
>> */
>> @@ -244,6 +280,9 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>> */
>> VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr));
>>
>> + if (is_kernel_image_addr(vmalloc_addr))
>> + return kernel_image_to_page(vmalloc_addr, pgd);
>
> It's not clear to me that this is the right place for this to live.
>
> It might be best to code the kernel image logic directly in kcore (and
> kmem), assuming everyone's OK with that approach.
>
That will fix kcore and kmem but this will show up in other places too.
We've gone through and made sure that virt_addr_valid returns
true if and only if virt_to_page returns a valid address. I don't know
if we can make as strong a claim about is_vmalloc_addr and
vmalloc_to_page in all cases but is_vmalloc_addr should not return true
for the kernel image. That would at least let kcore fall back to
kern_addr_valid which should correctly handle the kernel image.
The suggestion to move the kernel image out of VMALLOC_START/VMALLOC_END
seems like the best approach although I haven't tried a prototype
at all.
Thanks,
Laura
^ permalink raw reply
* [PATCH] arm64: pmuv3: Support v8.1 PMUv3 extension
From: Jayachandran C @ 2017-04-24 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424164507.GB5972@leverpostej>
On Mon, Apr 24, 2017 at 05:45:08PM +0100, Mark Rutland wrote:
> On Mon, Apr 24, 2017 at 04:40:09PM +0000, Jayachandran C wrote:
> > On Mon, Apr 24, 2017 at 03:03:48PM +0100, Mark Rutland wrote:
> > > On Mon, Apr 24, 2017 at 01:39:30PM +0000, Jayachandran C wrote:
> > > > The v8.1 supplement is quite clear on the field definition:
> > > >
> > > > PMUVer, bits [11:8]
> > > > ....
> > > > Defined values are:
> > > > 0000 Performance Monitors extension System registers not implemented.
> > > > 0001 Performance Monitors extension System registers implemented, PMUv3.
> > > > 0100 Performance Monitors extension System registers implemented, PMUv3, with a 16-bit
> > > > evtCount field, and if EL2 is implemented, the addition of the MDCR_EL2.HPMD bit.
> > > > 1111 IMPLEMENTATION DEFINED form of performance monitors supported, PMUv3 not
> > > > supported.
> > > > All other values are reserved.
> > > > In ARMv8-A the permitted values are 0b0000, 0b0001 and 0b1111.
> > > > In ARMv8.1 the permitted values are 0b0000, 0b0100 and 0b1111.
> > > >
> > > > I changed the code to strictly do this. We have to exclude 0xf, since that is not PMUv3.
> > > > And we cannot predict what the reserved values will represent, so it is best to skip them
> > > > until they are defined to be PMUv3 compatible.
> > >
> > > My understanding is that ID_AA64DFR0.PMUVer is intended to be covered by
> > > the usual ID register principles, and thus at least 0x2-0x7 are reserved
> > > for architected backwards compatible extensions to PMUv3.
> > >
> > > See ARM DDI 0487B.a, D7.1.4, "Principles of the ID scheme for fields in
> > > ID registers". It is explicitly stated that the scheme applies to
> > > ID_AA64DFR0.
> > >
> > > Per those rules, we should check >= the minimum PMUv3 implemented value,
> > > i.e. val >= 1. Due to both 0x0 and 0xF meaning PMUv3 isn't implemented,
> > > it's not clear if the fields should be treated as if it were signed or
> > > unsigned, and I'm awaiting clarification on this.
> >
> > Thanks for the reference. Since 0xf means that there is a PMU (but it is
> > not PMUv3), this looks like an unsigned ID with a special case.
> >
> > > Either way, I believe that 0x1-0x7 must all be compatible with baseline
> > > PMUv3 per the ID scheme principles.
> >
> > In case you don't get authoritative information on this, can you please
> > merge a version which does either 'if (pmuver < 1 || pmuver == 0xf)' or
> > 'if (pmuver < 1 || pmuver > 7)' to the patchset?
>
> Sure, that's what I proposed:
>
> pmuver = cpuid_feature_extract_signed_field(dfr0,
> ID_AA64DFR0_PMUVER_SHIFT);
> if (pmuver < 1)
> return;
>
> Note that it treats the value as signed, so it will accept 0x1-0x7, and
> return for 0x0 or 0x8-0xf.
Ok, we will need to change the type of pmuver to int as well.
But even then, I think the reasonable interpretation of the current spec
is that the field is unsigned. Your original 'if (pmuver < 1 || pmuver == 0xf)'
is the least surprising way of writing it.
JC.
^ permalink raw reply
* [Bug] VCHIQ functional test broken
From: Stefan Wahren @ 2017-04-24 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424164015.GP17774@n2100.armlinux.org.uk>
> Russell King - ARM Linux <linux@armlinux.org.uk> hat am 24. April 2017 um 18:40 geschrieben:
>
>
> On Mon, Apr 24, 2017 at 06:12:09PM +0200, Stefan Wahren wrote:
> > Am 20.04.2017 um 21:58 schrieb Rabin Vincent:
> > > On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
> > >> I'm confused by what you're saying here. The driver has already been
> > >> converted to not use dmac_map_area (commit
> > >> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
> > >> matching the radeon driver you give as a model as far as I can see.
> > >> That commit is in v4.11-rc6 from Stefan's regression report.
> > > Right. Sorry. I must have had an old tag checked out when I looked at
> > > the driver earlier. The DMA API usage in the driver in v4.11-rc6 and
> > > current master looks fine, except for one thing:
> > >
> > > The flush in flush_dcache_page() (from get_user_pages()) was done with a
> > > v6_flush_kern_dcache_page() which always did a clean+invalidate while
> > > the DMA API only does what is required by the direction, which is only a
> > > invalidate for DMA_FROM_DEVICE. Since the driver calls dma_from_sg() on
> > > the entire page, even if userspace sent in an offset into the page,
> > > unrelated data in userspace may be thrown away.
> > >
> > > Does changing the dma API calls to always use DMA_BIDIRECTIONAL make the
> > > test pass?
> >
> > Unfortunately not (at least not that simple).
> >
> > Do we need special DMA mapping attributes here ? Or a dma_sync_sg_for_* ?
>
> I had a look at the driver when you first reported the problem, but I
> don't see an obvious problem.
>
> In drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c, I
> see it using get_user_pages(), generating a scatterlist, which it then
> uses dma_map_sg() with. It then goes on to populate the DMA coherent
> buffer that it allocated with the DMA addresses of these buffers.
>
> The tear-down looks sane too - free_pagelist() looks like it correctly
> unmaps the scatterlist, marks the pages dirty if necessary, puts the
> pages and frees the DMA coherent memory.
>
> Since you're running on a PIPT cache, the only possible issue is whether
> there's a lifetime mismatch between what happens here, and what you're
> doing with the pages in userspace. All the rules wrt the DMA API apply
> to these userspace pages, just as these same rules apply in kernel space.
> Once you have called dma_map_sg() on them, any CPU access (whether
> explicit or speculative) will cause cache lines to be populated, and
> possibly marked dirty, which can have the effect of corrupting the data
> unless it is unmapped prior to the accesses you care about.
Just for the records, the link to the userspace program:
https://github.com/raspberrypi/userland/blob/master/interface/vchiq_arm/vchiq_test.c
Maybe there is an issue in the ioctl
>
> What I can't see is how changing flush_dcache_page() has possibly broken
> this: it seems to imply that you're getting flush_dcache_page() somehow
> called inbetween mapping it for DMA, using it for DMA and CPU accesses
> occuring. However, the driver doesn't call flush_dcache_page() other
> than through get_user_pages() - and since dma_map_sg() is used in that
> path, it should be fine.
>
> So, I don't have much to offer.
>
> However, flush_dcache_page() is probably still a tad heavy - it currently
> flushes to the point of coherency, but it's really about making sure that
> the user vs kernel mappings are coherent, not about device coherency.
> That's the role of the DMA API.
Currently i don't care too much about performance. More important is to fix this regression, because i'm not able to verify the function of this driver efficiently.
I'm thinking about 2 options:
1) add a force parameter to flush_dcache_page() which make it possible to override the new logic
2) create a second version of flush_dcache_page() with the old behavior
But first of all i need to figure out which parts of flush_dcache_page() are really necessary.
Many thanks anyway
>
> --
> 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.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] arm64/dma-mapping: fix DMA_ATTR_FORCE_CONTIGUOUS mmaping code
From: Catalin Marinas @ 2017-04-24 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXRkZGTd71emwVBpm4bWcuE--YR2avaMDZX=KG50zZ2Yg@mail.gmail.com>
Hi Geert,
On Fri, Apr 21, 2017 at 07:39:43PM +0200, Geert Uytterhoeven wrote:
> On Fri, Apr 21, 2017 at 7:32 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Fri, Mar 31, 2017 at 01:02:51PM +0200, Andrzej Hajda wrote:
> >> In case of DMA_ATTR_FORCE_CONTIGUOUS allocations vm_area->pages
> >> is invalid. __iommu_mmap_attrs and __iommu_get_sgtable should not
> >> use it and take advantage of contiguous nature of the allocation.
> >
> > As I replied to your original patch, I think
> > dma_common_contiguous_remap() should be fixed not to leave a dangling
> > area->pages pointer.
> >
> >> arch/arm64/mm/dma-mapping.c | 17 ++++++++++++++++-
> >> 1 file changed, 16 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> >> index f7b5401..41c7c36 100644
> >> --- a/arch/arm64/mm/dma-mapping.c
> >> +++ b/arch/arm64/mm/dma-mapping.c
> >> @@ -703,6 +703,10 @@ static int __iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
> >> if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
> >> return ret;
> >>
> >> + if (attrs & DMA_ATTR_FORCE_CONTIGUOUS)
> >> + return vm_iomap_memory(vma,
> >> + page_to_phys(vmalloc_to_page(cpu_addr)), size);
> >
> > I replied to Geert's patch on whether we actually need to call
> > dma_common_contiguous_remap() in __iommu_alloc_attrs() if the device is
> > coherent. We don't do this for the swiotlb allocation. If we are going
> > to change this, cpu_addr may or may not be in the vmalloc range and
> > vmalloc_to_page() would fail (I guess we could add an is_vmalloc_addr()
> > check).
> >
> > Alternatively, just open-code dma_common_contiguous_remap() in
> > __iommu_alloc_attrs() to keep a valid area->pages around (I think Geert
> > already suggested this). AFAICT, arch/arm does this already in its own
> > __iommu_alloc_buffer().
> >
> > Yet another option would be for iommu_dma_alloc() to understand
> > DMA_ATTR_FORCE_CONTIGUOUS and remove the arm64-specific handling.
>
> That was actually the approach I took in my v1.
> V2 changed that to provide standalone iommu_dma_{alloc,free}_contiguous()
> functions.
> V3 changed that to call everything directly from the arm64 code.
> ...
I now read through the past discussions (as I ignored the threads
previously). I got Robin's point of not extending iommu_dma_alloc()
(though it looked simpler) and open-coding dma_common_contiguous_remap()
wouldn't make sense either as a way to pass this buffer to
iommu_dma_mmap() since it wasn't returned by iommu_dma_alloc().
So I think we should just fall back to the swiotlb ops for the mmap and
get_sgtable but since we don't have a dma_addr_t handle (we only have
the one of the other side of the IOMMU), we'd need to factor out the
common code from __swiotlb_mmap into a __swiotlb_mmap_page (similarly
for __swiotlb_get_sgtable). The __iommu_* functions would call these
with the correct page (from vmalloc_to_page) if
DMA_ATTR_FORCE_CONTIGUOUS and the buffer is not a candidate for
*_from_coherent.
While fixing/removing dma_get_sgtable() is a nice goal, we first need to
address DMA_ATTR_FORCE_CONTIGUOUS on arm64 since the patch breaks
existing use-cases (and I'd like to avoid reverting this patch).
--
Catalin
^ permalink raw reply
* [PATCH 3/5] Memory hotplug support for arm64 platform (v2)
From: Maciej Bielski @ 2017-04-24 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170411155843.GC32267@leverpostej>
Hi Mark,
Thank you for having a look on the code and providing comments. Same to others
that replied to the whole patchset. To the large extent, first purpose of this code
was to just to implement the functionality and I am totally aware that it may
be suboptimal at some places and therefore your feedback is very much
appreciated.
More answers below.
On Tue, Apr 11, 2017 at 04:58:43PM +0100, Mark Rutland wrote:
> Hi,
>
> On Tue, Apr 11, 2017 at 03:55:22PM +0100, Andrea Reale wrote:
> > From: Maciej Bielski <m.bielski@virtualopensystems.com>
> >
> > This is a second and improved version of the patch previously released
> > in [3].
> >
> > It builds on the work by Scott Branden [2] and, henceforth,
> > it needs to be applied on top of Scott's patches [2].
> > Comments are very welcome.
> >
> > Changes from the original patchset and known issues:
> >
> > - Compared to Scott's original patchset, this work adds the mapping of
> > the new hotplugged pages into the kernel page tables. This is done by
> > copying the old swapper_pg_dir over a new page, adding the new mappings,
> > and then switching to the newly built pg_dir (see `hotplug_paging` in
> > arch/arm64/mmu.c). There might be better ways to to this: suggestions
> > are more than welcome.
>
> For this reply, I'm just going to focus on the PGD replacement.
>
> It's not clear to me if we need to swap the PGD, since everything we do
> here is strictly additive and non-conflicting, and it should be safe to
> add things to the swapper_pg_dir live.
>
> However, assuming there's something I've missed, I have some comments
> below.
>
> [...]
For one CPU it should work, I have quickly checked on QEMU. More concerns
regarding multiple CPUs below(*).
>
> > +#ifdef CONFIG_MEMORY_HOTPLUG
> > +
> > +/*
> > + * hotplug_paging() is used by memory hotplug to build new page tables
> > + * for hot added memory.
> > + */
> > +void hotplug_paging(phys_addr_t start, phys_addr_t size)
> > +{
> > +
> > + struct page *pg;
> > + phys_addr_t pgd_phys = pgd_pgtable_alloc();
> > + pgd_t *pgd = pgd_set_fixmap(pgd_phys);
> > +
> > + memcpy(pgd, swapper_pg_dir, PAGE_SIZE);
>
> s/PAGE_SIZE/PGD_SIZE/ (and below, too).
>
> See commit 12f043ff2b28fa64 ("arm64: fix warning about swapper_pg_dir
> overflow").
>
Noted, thanks.
> > +
> > + __create_pgd_mapping(pgd, start, __phys_to_virt(start), size,
> > + PAGE_KERNEL, pgd_pgtable_alloc, false);
> > +
> > + cpu_replace_ttbr1(__va(pgd_phys));
>
> Other CPUs may be online at this point, and cpu_replace_ttbr1() was only
> intended for UP operation. Other CPUs will still have swapper_pg_dir in
> their TTBR1_EL1 at this point in time...
>
> > + memcpy(swapper_pg_dir, pgd, PAGE_SIZE);
>
> ... which this will alter, in an unsafe fashion.
>
> The other CPUs are live, and might be altering swapper. e.g. one might
> be using the fixmap to alter code. We will need some stop_machine()-like
> machinery here to synchronise with other CPUs, ensuring that they don't
> have swapper_pg_dir live.
(*)
I am familiar with stop_machine(), for example it is done at later stage, when
pages are onlined (inside build_all_zonelists). But do you think that we should
check if swapper_pg_dir is under modification before stopping (and optionally
wait until this modification is finished)? Is there a mechanism to serialize
the write access to swapper_pg_dir?
>
> Unfortunately, we can't change other to the temporary pgdir in a cross
> call, then fix things up, then do another cross call. If any exception
> is taken when we're in the temporary pgdir, __uaccess_ttbr0_disable will
> install junk into TTBR0, and we risk the usual set of pain junk TLBs
> entail.
>
> We appear to have a latent bug at boot time along those lines, when
> setting up the page tables and initialising KASAN. I'll see about
> cleaning that up.
Great, thank you for any hints.
>
> Thanks,
> Mark.
Best regards,
--
Maciej Bielski
^ permalink raw reply
* [PATCH] arm64: Add ASM modifier for xN register operands
From: Will Deacon @ 2017-04-24 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_Ms73qfFFjmhkwF9Rh2jBM6Cx9LfuSHPUnXv0GTR1z7w@mail.gmail.com>
On Mon, Apr 24, 2017 at 06:22:51PM +0100, Ard Biesheuvel wrote:
> On 24 April 2017 at 18:00, Will Deacon <will.deacon@arm.com> wrote:
> > Hi Matthias,
> >
> > On Thu, Apr 20, 2017 at 11:30:53AM -0700, Matthias Kaehlcke wrote:
> >> Many inline assembly statements don't include the 'x' modifier when
> >> using xN registers as operands. This is perfectly valid, however it
> >> causes clang to raise warnings like this:
> >>
> >> warning: value size does not match register size specified by the
> >> constraint and modifier [-Wasm-operand-widths]
> >> ...
> >> arch/arm64/include/asm/barrier.h:62:23: note: expanded from macro
> >> '__smp_store_release'
> >> asm volatile ("stlr %1, %0"
> >
> > If I understand this correctly, then the warning is emitted when we pass
> > in a value smaller than 64-bit, but refer to %<n> without a modifier
> > in the inline asm.
> >
> > However, if that's the case then I don't understand why:
> >
> >> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> >> index 0c00c87bb9dd..021e1733da0c 100644
> >> --- a/arch/arm64/include/asm/io.h
> >> +++ b/arch/arm64/include/asm/io.h
> >> @@ -39,33 +39,33 @@
> >> #define __raw_writeb __raw_writeb
> >> static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
> >> {
> >> - asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
> >> + asm volatile("strb %w0, [%x1]" : : "rZ" (val), "r" (addr));
> >
> > is necessary. addr is a pointer type, so is 64-bit.
> >
> > Given that the scattergun nature of this patch implies that you've been
> > fixing the places where warnings are reported, then I'm confused as to
> > why a warning is generated for the case above.
> >
> > What am I missing?
> >
>
> AIUI, Clang now always complains for missing register width modifiers,
> not just for placeholders that resolve to a 32-bit (or smaller)
> quantity.
Ok, in which case this patch is incomplete as there's a bunch of asm that
isn't updated (e.g. spinlock.h).
Will
^ permalink raw reply
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Arnd Bergmann @ 2017-04-24 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.20.1704241249350.32200@eddie.linux-mips.org>
On Mon, Apr 24, 2017 at 6:53 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Mon, 24 Apr 2017, Arnd Bergmann wrote:
>
>> > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not
>> > do it.I guess most people using old compilers know what they're doing.
>>
>> What I'm trying to find out first is whether "people regularly using 10+
>> year old compilers for the latest kernels" is a strict subset of "people in
>> Geert's household".
>
> Well I do not live with Geert TBH.
Sorry about that, you had mentioned that you had used it recently, which should
have weighed more than my own results.
> Linux 4.11-rc8
> $ /usr/bin/time make ARCH=mips CROSS_COMPILE=mipsel-linux- decstation_defconfig vmlinux >/dev/null 2>&1
> 1014.19user 71.47system 19:33.24elapsed 92%CPU (0avgtext+0avgdata
> 0maxresident)k18764inputs+242504outputs (704major+9549837minor)pagefaults 0swaps
> $ mipsel-linux-gcc --version
> gcc (GCC) 4.1.2
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $
>
> Methinks it builds just fine.
I must have done something wrong:
I tried a few defconfigs with a latest kernel and compiler and they all failed,
found linux-4.3 to be the first version that was broken for all of them
(most with a link time error, some with missing gcc features)
I later tried all mips defconfigs with linux-4.3 and they all failed
with gcc-4.1.3
but built fine with gcc-4.9. I've now tried decstation_defconfig in 4.8-rc11,
and this is what I see for gcc-4.1.3
make O=build/mips/decstation_defconfig/ -skj30
CC=/home/arnd/cross-gcc/bin/mips-linux-gcc-4.1.3\ ARCH=mips -f
Makefile CROSS_COMPILE=/home/arnd/cross-gcc/bin/mips-linux-
/git/arm-soc/fs/dcache.c: In function '__d_move':
/git/arm-soc/fs/dcache.c:2773: warning: 'n' may be used uninitialized
in this function
/git/arm-soc/fs/dcache.c: In function 'd_splice_alias':
/git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized
in this function
/git/arm-soc/fs/dcache.c: In function 'd_add':
/git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized
in this function
/git/arm-soc/mm/page-writeback.c: In function 'balance_dirty_pages_ratelimited':
/git/arm-soc/mm/page-writeback.c:1627: warning: 'writeback' is used
uninitialized in this function
/git/arm-soc/mm/page-writeback.c:1628: warning: 'filepages' is used
uninitialized in this function
/git/arm-soc/mm/page-writeback.c:1628: warning: 'headroom' is used
uninitialized in this function
/git/arm-soc/mm/page-writeback.c: In function 'wb_over_bg_thresh':
/git/arm-soc/mm/page-writeback.c:1956: warning: 'filepages' is used
uninitialized in this function
/git/arm-soc/mm/page-writeback.c:1956: warning: 'headroom' is used
uninitialized in this function
/git/arm-soc/net/core/flow_dissector.c: In function '__skb_flow_dissect':
/git/arm-soc/net/core/flow_dissector.c:272: warning: 'vlan' may be
used uninitialized in this function
/git/arm-soc/fs/splice.c: In function 'iter_file_splice_write':
/git/arm-soc/fs/splice.c:716: warning: 'ret' may be used uninitialized
in this function
/git/arm-soc/net/core/dev.c: In function 'validate_xmit_skb_list':
/git/arm-soc/net/core/dev.c:3003: warning: 'tail' may be used
uninitialized in this function
/git/arm-soc/kernel/printk/printk.c: In function 'devkmsg_sysctl_set_loglvl':
/git/arm-soc/kernel/printk/printk.c:161: warning: 'old' may be used
uninitialized in this function
/git/arm-soc/kernel/time/ntp.c: In function 'ntp_validate_timex':
/git/arm-soc/kernel/time/ntp.c:707: warning: comparison is always
false due to limited range of data type
/git/arm-soc/kernel/time/ntp.c:709: warning: comparison is always
false due to limited range of data type
/git/arm-soc/kernel/time/timekeeping.c: In function
'get_device_system_crosststamp':
/git/arm-soc/kernel/time/timekeeping.c:1084: warning:
'cs_was_changed_seq' may be used uninitialized in this function
/git/arm-soc/net/sunrpc/xdr.c: In function 'xdr_stream_decode_string_dup':
/git/arm-soc/include/linux/sunrpc/xdr.h:409: warning: 'len' may be
used uninitialized in this function
/git/arm-soc/crypto/drbg.c: In function 'drbg_kcapi_random':
/git/arm-soc/crypto/drbg.c:1865: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
/git/arm-soc/scripts/Makefile.build:300: recipe for target
'crypto/drbg.o' failed
So it still fails, but only because of one compiler error that I can avoid by
disabling that driver, and you probably use a slightly patched compiler
version that doesn't have this particular bug, or it was a regression between
gcc-4.1.2 and 4.1.3.
Arnd
^ permalink raw reply
* [PATCH] arm64: Add ASM modifier for xN register operands
From: Ard Biesheuvel @ 2017-04-24 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424170009.GT12323@arm.com>
On 24 April 2017 at 18:00, Will Deacon <will.deacon@arm.com> wrote:
> Hi Matthias,
>
> On Thu, Apr 20, 2017 at 11:30:53AM -0700, Matthias Kaehlcke wrote:
>> Many inline assembly statements don't include the 'x' modifier when
>> using xN registers as operands. This is perfectly valid, however it
>> causes clang to raise warnings like this:
>>
>> warning: value size does not match register size specified by the
>> constraint and modifier [-Wasm-operand-widths]
>> ...
>> arch/arm64/include/asm/barrier.h:62:23: note: expanded from macro
>> '__smp_store_release'
>> asm volatile ("stlr %1, %0"
>
> If I understand this correctly, then the warning is emitted when we pass
> in a value smaller than 64-bit, but refer to %<n> without a modifier
> in the inline asm.
>
> However, if that's the case then I don't understand why:
>
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 0c00c87bb9dd..021e1733da0c 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -39,33 +39,33 @@
>> #define __raw_writeb __raw_writeb
>> static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
>> {
>> - asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
>> + asm volatile("strb %w0, [%x1]" : : "rZ" (val), "r" (addr));
>
> is necessary. addr is a pointer type, so is 64-bit.
>
> Given that the scattergun nature of this patch implies that you've been
> fixing the places where warnings are reported, then I'm confused as to
> why a warning is generated for the case above.
>
> What am I missing?
>
AIUI, Clang now always complains for missing register width modifiers,
not just for placeholders that resolve to a 32-bit (or smaller)
quantity.
^ permalink raw reply
* [PATCH] arm64: dts: freescale: ls2081ardb: Add DTS support for NXP LS2081ARDB
From: Yang Li @ 2017-04-24 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492663067-2364-1-git-send-email-priyanka.jain@nxp.com>
We probably should rename the freescale folder to nxp with a separate
patch, but it is better to stop using the name in the patch title
right now.
On Wed, Apr 19, 2017 at 11:37 PM, Priyanka Jain <priyanka.jain@nxp.com> wrote:
> This patch add support for NXP LS2081ARDB board which has
> LS2081A SoC.
>
> LS2081A SoC is 40-pin derivative of LS2088A SoC
> So, from functional perspective both are same.
> Hence,ls2088a SoC dtsi files are included from ls2081ARDB dts
>
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts | 139 +++++++++++++++++++++
> 2 files changed, 140 insertions(+), 0 deletions(-)
> create mode 100755 arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 72c4b52..58b80de 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2081a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> new file mode 100444
> index 0000000..7ae408e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> @@ -0,0 +1,139 @@
> +/*
> + * Device Tree file for NXP LS2081A RDB Board.
> + *
> + * Copyright (C) 2017, NXP Semiconductors
The formal copyright claim formal should be
Copyright 2017 NXP
> + *
> + * Priyanka Jain <priyanka.jain@nxp.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "fsl-ls2088a.dtsi"
> +
> +/ {
> + model = "NXP Layerscape 2081A RDB Board";
> + compatible = "fsl,ls2081a-rdb", "fsl,ls2081a";
> +
> + aliases {
> + serial0 = &serial0;
> + serial1 = &serial1;
> + };
> +
> + chosen {
> + stdout-path = "serial1:115200n8";
> + };
> +};
> +
> +&esdhc {
> + status = "okay";
> +};
> +
> +&ifc {
> + status = "disabled";
> +};
> +
> +&i2c0 {
> + status = "okay";
> + pca9547 at 75 {
> + compatible = "nxp,pca9547";
> + reg = <0x75>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + i2c at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x01>;
> + rtc at 51 {
> + compatible = "nxp,pcf2129";
> + reg = <0x51>;
> + };
> + };
> +
> + i2c at 3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x3>;
> +
> + adt7481 at 4c {
> + compatible = "adi,adt7461";
> + reg = <0x4c>;
> + };
> + };
> + };
> +};
> +
> +&dspi {
> + status = "okay";
> + dflash0: n25q512a {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,m25p80";
> + spi-max-frequency = <3000000>;
> + reg = <0>;
> + };
> +};
> +
> +
> +&qspi {
> + status = "okay";
> + flash0: n25q512a at 0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,m25p80";
> + spi-max-frequency = <20000000>;
> + reg = <0>;
> + };
> + flash1: n25q512a at 1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,m25p80";
> + spi-max-frequency = <20000000>;
> + reg = <0>;
> + };
> +};
> +
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
> --
> 1.7.4.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
- Leo
^ permalink raw reply
* [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt
From: James Morse @ 2017-04-24 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2bb41d98-553f-1361-e497-4095ddd501d0@huawei.com>
Hi Wang Xiongfeng,
On 21/04/17 12:33, Xiongfeng Wang wrote:
> On 2017/4/20 16:52, James Morse wrote:
>> On 19/04/17 03:37, Xiongfeng Wang wrote:
>>> On 2017/4/18 18:51, James Morse wrote:
>>>> The host expects to receive physical SError Interrupts. The ARM-ARM doesn't
>>>> describe a way to inject these as they are generated by the CPU.
>>>>
>>>> Am I right in thinking you want this to use SError Interrupts as an APEI
>>>> notification? (This isn't a CPU thing so the RAS spec doesn't cover this use)
>>>
>>> Yes, using sei as an APEI notification is one part of my consideration. Another use is for ESB.
>>> RAS spec 6.5.3 'Example software sequences: Variant: asynchronous External Abort with ESB'
>>> describes the SEI recovery process when ESB is implemented.
>>>
>>> In this situation, SEI is routed to EL3 (SCR_EL3.EA = 1). When an SEI occurs in EL0 and not been taken immediately,
>>> and then an ESB instruction at SVC entry is executed, SEI is taken to EL3. The ESB at SVC entry is
>>> used for preventing the error propagating from user space to kernel space. The EL3 SEI handler collects
>>
>>> the errors and fills in the APEI table, and then jump to EL2 SEI handler. EL2 SEI handler inject
>>> an vSEI into EL1 by setting HCR_EL2.VSE = 1, so that when returned to OS, an SEI is pending.
>>
>> This step has confused me. How would this work with VHE where the host runs at
>> EL2 and there is nothing at Host:EL1?
>
> RAS spec 6.5.3 'Example software sequences: Variant: asynchronous External Abort with ESB'
> I don't know whether the step described in the section is designed for guest os or host os or both.
> Yes, it doesn't work with VHE where the host runs at EL2.
If it uses Virtual SError, it must be for an OS running at EL1, as the code
running at EL2 (VHE:Linux, firmware or Xen) must set HCR_EL2.AMO to make this work.
I can't find the section you describe in this RAS spec:
https://developer.arm.com/docs/ddi0587/latest/armreliabilityavailabilityandserviceabilityrasspecificationarmv8forthearmv8aarchitectureprofile
>> >From your description I assume you have some firmware resident at EL2.
> Our actual SEI step is planned as follows:
Ah, okay. You can't use Virtual SError at all then, as firmware doesn't own EL2:
KVM does. KVM will save/restore the HCR_EL2 register as part of its world
switch. Firmware must not modify the hyp registers behind the hyper-visors back.
> Host OS: EL0/EL1 -> EL3 -> EL0/EL1
i.e. While the host was running, so EL3 sees HCR_EL2.AMO clear, and directs the
SEI to EL1.
> Guest OS: EL0/EL1 -> EL3 -> EL2 -> EL0/EL1
i.e. While the guest was running, so EL3 sees HCR_EL2.AMO set, directs the SEI
to EL2 where KVM performs the world-switch and returns to host EL1.
Looks sensible.
> In guest os situation, we can inject an vSEI and return to where the SEI is taken from.
An SEI from firmware should always end up in the host OS. If a guest was running
KVM is responsible for doing the world switch to restore host EL1 and return
there. This should all work today.
> But in host os situation, we can't inject an vSEI (if we don't set HCR_EL2.AMO), so we have to jump to EL1 SEI vector.
Because your firmware is at EL3 you have to check PSTATE.A and jump into the
SError vector in both cases, you just choose if its VBAR_EL2 or VBAR_EL1 based
on HCR_EL2.AMO.
> Then the process following ESB won't be executed becuase SEI is taken to EL3 from the ESB instruction in EL1, and when control
> is returned to OS, we are in EL1 SEI vector rather than the ESB instruction.
Firmware should set ELR_EL1 so that an eret from the EL1 SError vector takes you
back to the ESB instruction that took us to EL3 in the first place.
There is a problem here mixing SError as the CPU->Software notification of RAS
errors and as APEI's SEI Software->Software notification that a firmware-first
error has been handled by EL3.
To elaborate:
The routine in this patch was something like:
1 ESB
2 Read DISR_EL1
3 If set, branch to the SError handler.
If we have firmware-first ESB will generate an SError as PSTATE.A at EL{1,2}
doesn't mask SError for EL3. Firmware can then handle the RAS error. With this
the CPU->Software story is done. Firmware notifying the OS via APEI is a
different problem.
If the error doesn't need to be notified to the OS via SEI, firmware can return
to step 1 above with DISR_EL1 clear. The OS may be told via another mechanism
such as polling or an irq.
If PSTATE.A was clear, firmware can return to the SError vector. If PSTATE.A was
set and firmware knows this was due to an ESB, it can set DISR_EL1. The problem
is firmware can't know if the SError was due to an ESB.
The only time we are likely to have PSTATE.A masked is when changing exception
level. For this we can rely on IESB, so step 1 isn't necessary in the routine
above. Firmware knows if an SError taken to EL3 is due to an IESB, as the
ESR_EL3.IESB bit will be set, in this case it can write to DISR_EL1 and return.
In Linux we can use IESB for changes in exception level, and ESB with PSTATE.A
clear for any other need. (e.g. __switch_to()). Firmware can notify us using SEI
if we use either of these two patterns. This may not work for other OS (Xen?),
but this is a problem with using SEI as an APEI notification method.
(Some cleanup of our SError unmasking is needed, I have some patches I will post
on a branch shortly)
> It is ok to just ignore the process following the ESB instruction in el0_sync, because the process will be sent SIGBUS signal.
I don't understand. How will Linux know the process caused an error if we
neither take an SError nor read DISR_EL1 after an ESB?
> But for el0_irq, the irq process following the ESB may should be executed because the irq is not related to the user process.
If we exit EL0 for an IRQ, and take an SError due to IESB we know the fault was
due to EL0, not the exception level we entered to process the IRQ.
> If we set HCR_EL2.AMO when SCR_EL3.EA is set. We can still inject an vSEI into host OS in EL3.
(from EL3?) Only if the host OS is running at EL1 and isn't using EL2. Firmware
can't know if we're using EL2 so this can't work.
> Physical SError won't be taken to EL2 because SCR_EL3.EA is set. But this may be too racy is
> not consistent with ARM rules.
EL3 flipping bits in EL2 system registers behind EL2 software's back is going to
have strange side effects. e.g. some Hypervisor may not change HCR_EL2 when
switching VM-A to VM-B as the configuration is the same; now the virtual SError
will be delivered to the wrong VM. (KVM doesn't do this, but Xen might.)
>>>> You cant use SError to cover all the possible RAS exceptions. We already have
>>>> this problem using SEI if PSTATE.A was set and the exception was an imprecise
>>>> abort from EL2. We can't return to the interrupted context and we can't deliver
>>>> an SError to EL2 either.
>>>
>>> SEI came from EL2 and PSTATE.A is set. Is it the situation where VHE is enabled and CPU is running
>>> in kernel space. If SEI occurs in kernel space, can we just panic or shutdown.
>>
>> firmware-panic? We can do a little better than that:
>> If the IESB bit is set in the ESR we can behave as if this were an ESB and have
>> firmware write an appropriate ESR to DISR_EL1 if PSTATE.A is set and the
>> exception came from EL2.
>
> This method may solve the problem I said above.
> Is IESB a new bit added int ESR in the newest RAS spec?
The latest ARM-ARM (DDI0487B.a) describes it as part of the "RAS Extension in
ARMv8.2" in section 'A1.7.5 The Reliability, Availability, and Serviceability
(RAS) Extension'.
Jumping to 'D7.2.28 ESR_ELx, Exception Syndrome Register (ELx)', then page
D7-2284 for the 'ISS encoding for an SError interrupt', it indicates "the SError
interrupt was synchronized by the implicit [ESB] and taken immediately"
As above, with IESB for changes in exception level, and unmasking PSTATE.A for
any other use of ESB, Linux can make sure that firmware can always notify us of
an APEI event using SEI.
Another OS (or even UEFI) may not do the same, so firmware should be prepared
for ESB to be executed with PSTATE.A masked (i.e, not using IESB). If there is
no wider firmware-policy for this (reboot, notify a remote CPU), then returning
to the faulting location and trying to inject SError later is all we can do.
Thanks,
James
^ permalink raw reply
* [PATCH 4/5 v3] usb: host: fotg2: add Gemini-specific handling
From: Hans Ulli Kroll @ 2017-04-24 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421204058.6206-4-linus.walleij@linaro.org>
Hi Linus
On Fri, 21 Apr 2017, Linus Walleij wrote:
> The Cortina Systems Gemini has bolted on a PHY inside the
> silicon that can be handled by six bits in a MISC register in
> the system controller.
>
> If we are running on Gemini, look up a syscon regmap through
> a phandle and enable VBUS and optionally the Mini-B connector.
>
> If the device is flagged as "wakeup-source" using the standard
> DT bindings, we also enable this in the global controller for
> respective port.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/usb/host/Kconfig | 1 +
> drivers/usb/host/fotg210-hcd.c | 76 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 77 insertions(+)
>
please wait for a while, I'm working on some glue code to support both
host and device mode on FOTG.
Hans Ulli Kroll
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Increase SMMU CMD queue poll timeout
From: Will Deacon @ 2017-04-24 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+sq2CeyVm4pcAVME7OAFVxpOcSJc5CsP0vz3ypDkSxdx0SKnQ@mail.gmail.com>
On Mon, Apr 24, 2017 at 10:26:53PM +0530, Sunil Kovvuri wrote:
> On Mon, Apr 24, 2017 at 9:38 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Mon, Apr 24, 2017 at 05:29:36PM +0530, Geetha sowjanya wrote:
> >> From: Geetha <gakula@cavium.com>
> >>
> >> When large memory is being unmapped, huge no of tlb invalidation cmds are
> >> submitted followed by a SYNC command. This sometimes hits CMD queue full and
> >> poll on queue drain is being timedout throwing error message 'CMD_SYNC timeout'.
> >>
> >> Although there is no functional issue, error message confuses user. Hence increased
> >> poll timeout to 500us
> >
> > Hmm, what are you doing to unmap that much? Is this VFIO teardown? Do you
> > have 7c6d90e2bb1a ("iommu/io-pgtable-arm: Fix iova_to_phys for block
> > entries") applied?
>
> Yes it's VFIO teardown and again yes the above fix is applied.
> But i didn't get how above fix is related.
> TLB invalidation commands are submitted at 'arm_smmu_tlb_inv_range_nosync()'
> and it's a loop over granule size.
>
> 1357 do {
> 1358 arm_smmu_cmdq_issue_cmd(smmu, &cmd);
> 1359 cmd.tlbi.addr += granule;
> 1360 } while (size -= granule);
>
> So if invalidation size is big then huge no of invalidation commands
> will be submitted
> irrespective of fix that you pointed above, right ?
VFIO has some logic to batch up invalidations, but this didn't work properly
for us without the fix above. However, I guess you have a huge memory range
that's mapped with 2M sections or something, so there are still loads of
entries to invalidate.
I would much prefer it if VFIO could just teardown the whole address space
so that we could do an invalidate all, but there's a chicken-and-egg problem
with page accounting iirc.
Will
^ permalink raw reply
* [PATCH 1/1] PCI: Add MCFG quirk for 2nd node of Cavium ThunderX pass2.x host controller
From: Bjorn Helgaas @ 2017-04-24 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424093429.GT16981@rric.localdomain>
On Mon, Apr 24, 2017 at 4:34 AM, Robert Richter
<robert.richter@cavium.com> wrote:
> On 21.04.17 11:56:14, Bjorn Helgaas wrote:
>> On Wed, Mar 29, 2017 at 02:16:13PM +0200, Tomasz Nowicki wrote:
>> > Currently SoCs pass2.x do not emulate EA headers for ACPI boot method at all.
>> > However, for pass2.x some devices (like EDAC) advertise incorrect base addresses
>> > in their BARs which results in driver probe failure during resource request.
>> > Since all problematic blocks are on 2nd NUMA node under domain 10 add necessary
>> > quirk entry to obtain BAR addresses correction using EA header emulation.
>> >
>> > Fixes: 44f22bd91e88 ("PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controller")
>> > Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> > CC: stable at vger.kernel.org # v4.10+
>>
>> Sorry Tomasz, I must have mistakenly marked this "accepted" in
>> patchwork, so it fell off my to-do list. It's too late to get this in
>> v4.11, but I can still apply it for v4.12.
>>
>> I put it on my pci/host-thunder branch with Robert's ack. I added a preceding
>> patch to tidy up whitespace, which makes this patch look like just:
>>
>> /* SoC pass2.x */
>> THUNDER_PEM_QUIRK(1, 0),
>> THUNDER_PEM_QUIRK(1, 1),
>> + THUNDER_ECAM_QUIRK(1, 10),
>>
>> Please double-check it to make sure this is what you need.
>
> Bjorn,
>
> since the second is marked stable there will be conflicts when
> applying it to stable (or built errors). The best would be to change
> order of both (128cd6e8249f^, 128cd6e8249f) for smooth backporting
> which makes it then more close to Tomasz's version again.
Thanks, I should have noticed that. Could go either way; I just
marked 128cd6e8249f^ for stable as well, since it seemed marginally
easier to read to split the whitespace changes from the real change.
>> > ---
>> > drivers/acpi/pci_mcfg.c | 7 ++++---
>> > 1 file changed, 4 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> > index a6a4cea..a0a391e 100644
>> > --- a/drivers/acpi/pci_mcfg.c
>> > +++ b/drivers/acpi/pci_mcfg.c
>> > @@ -90,13 +90,14 @@ static struct mcfg_fixup mcfg_quirks[] = {
>> > &thunder_pem_ecam_ops, THUNDER_PEM_RES(0x894057000000UL, node) }, \
>> > { "CAVIUM", "THUNDERX", rev, 9 + (10 * (node)), MCFG_BUS_ANY, \
>> > &thunder_pem_ecam_ops, THUNDER_PEM_RES(0x89808f000000UL, node) }
>> > +#define THUNDER_ECAM_QUIRK(rev, seg) \
>> > + { "CAVIUM", "THUNDERX", rev, seg, MCFG_BUS_ANY, \
>> > + &pci_thunder_ecam_ops }
>> > /* SoC pass2.x */
>> > THUNDER_PEM_QUIRK(1, 0),
>> > THUNDER_PEM_QUIRK(1, 1),
>> > + THUNDER_ECAM_QUIRK(1, 10),
>> >
>> > -#define THUNDER_ECAM_QUIRK(rev, seg) \
>> > - { "CAVIUM", "THUNDERX", rev, seg, MCFG_BUS_ANY, \
>> > - &pci_thunder_ecam_ops }
>> > /* SoC pass1.x */
>> > THUNDER_PEM_QUIRK(2, 0), /* off-chip devices */
>> > THUNDER_PEM_QUIRK(2, 1), /* off-chip devices */
>> > --
>> > 2.7.4
>> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] arm64: Add ASM modifier for xN register operands
From: Will Deacon @ 2017-04-24 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420183053.718-1-mka@chromium.org>
Hi Matthias,
On Thu, Apr 20, 2017 at 11:30:53AM -0700, Matthias Kaehlcke wrote:
> Many inline assembly statements don't include the 'x' modifier when
> using xN registers as operands. This is perfectly valid, however it
> causes clang to raise warnings like this:
>
> warning: value size does not match register size specified by the
> constraint and modifier [-Wasm-operand-widths]
> ...
> arch/arm64/include/asm/barrier.h:62:23: note: expanded from macro
> '__smp_store_release'
> asm volatile ("stlr %1, %0"
If I understand this correctly, then the warning is emitted when we pass
in a value smaller than 64-bit, but refer to %<n> without a modifier
in the inline asm.
However, if that's the case then I don't understand why:
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 0c00c87bb9dd..021e1733da0c 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -39,33 +39,33 @@
> #define __raw_writeb __raw_writeb
> static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
> {
> - asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
> + asm volatile("strb %w0, [%x1]" : : "rZ" (val), "r" (addr));
is necessary. addr is a pointer type, so is 64-bit.
Given that the scattergun nature of this patch implies that you've been
fixing the places where warnings are reported, then I'm confused as to
why a warning is generated for the case above.
What am I missing?
Will
^ permalink raw reply
* [PATCH] arm64/dma-mapping: fix DMA_ATTR_FORCE_CONTIGUOUS mmaping code
From: Laura Abbott @ 2017-04-24 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421161234.GD5312@e104818-lin.cambridge.arm.com>
On 04/21/2017 09:12 AM, Catalin Marinas wrote:
> On Wed, Mar 29, 2017 at 01:55:32PM +0100, Robin Murphy wrote:
>> On 29/03/17 11:05, Andrzej Hajda wrote:
>>> In case of DMA_ATTR_FORCE_CONTIGUOUS allocations vm_area->pages
>>> is invalid. __iommu_mmap_attrs and __iommu_get_sgtable cannot use
>>> it. In first case temporary pages array is passed to iommu_dma_mmap,
>>> in 2nd case single entry sg table is created directly instead
>>> of calling helper.
>>>
>>> Fixes: 44176bb ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU")
>>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
>>> ---
>>> Hi,
>>>
>>> I am not familiar with this framework so please don't be too cruel ;)
>>> Alternative solution I see is to always create vm_area->pages,
>>> I do not know which approach is preferred.
>>>
>>> Regards
>>> Andrzej
>>> ---
>>> arch/arm64/mm/dma-mapping.c | 40 ++++++++++++++++++++++++++++++++++++++--
>>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>>> index f7b5401..bba2bc8 100644
>>> --- a/arch/arm64/mm/dma-mapping.c
>>> +++ b/arch/arm64/mm/dma-mapping.c
>>> @@ -704,7 +704,30 @@ static int __iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
>>> return ret;
>>>
>>> area = find_vm_area(cpu_addr);
>>> - if (WARN_ON(!area || !area->pages))
>>> + if (WARN_ON(!area))
>>
>> From the look of things, it doesn't seem strictly necessary to change
>> this, but whether that's a good thing is another matter. I'm not sure
>> that dma_common_contiguous_remap() should really be leaving a dangling
>> pointer in area->pages as it apparently does... :/
>
> On this specific point, I don't think area->pages should be set either
> (cc'ing Laura). As in the vmalloc vs vmap case, area->pages when pages
> need to be freed (via vfree), which is not the case here. The
> dma_common_pages_remap() would need to set area->pages when called
> directly from the iommu DMA ops. Proposal below, not tested with the
> iommu ops. I assume the patch would cause __iommu_mmap_attrs() to return
> -ENXIO if DMA_ATTR_FORCE_CONTIGUOUS is set.
>
> ------------8<---------------------------------
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index efd71cf4fdea..ab7071041141 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -277,8 +277,8 @@ EXPORT_SYMBOL(dma_common_mmap);
> * remaps an array of PAGE_SIZE pages into another vm_area
> * Cannot be used in non-sleeping contexts
> */
> -void *dma_common_pages_remap(struct page **pages, size_t size,
> - unsigned long vm_flags, pgprot_t prot,
> +static struct vm_struct *__dma_common_pages_remap(struct page **pages,
> + size_t size, unsigned long vm_flags, pgprot_t prot,
> const void *caller)
> {
> struct vm_struct *area;
> @@ -287,13 +287,26 @@ void *dma_common_pages_remap(struct page **pages, size_t size,
> if (!area)
> return NULL;
>
> - area->pages = pages;
> -
> if (map_vm_area(area, prot, pages)) {
> vunmap(area->addr);
> return NULL;
> }
>
> + return area;
> +}
> +
> +void *dma_common_pages_remap(struct page **pages, size_t size,
> + unsigned long vm_flags, pgprot_t prot,
> + const void *caller)
> +{
> + struct vm_struct *area;
> +
> + area = __dma_common_pages_remap(pages, size, vm_flags, prot, caller);
> + if (!area)
> + return NULL;
> +
> + area->pages = pages;
> +
> return area->addr;
> }
>
> @@ -308,7 +321,7 @@ void *dma_common_contiguous_remap(struct page *page, size_t size,
> {
> int i;
> struct page **pages;
> - void *ptr;
> + struct vm_struct *area;
> unsigned long pfn;
>
> pages = kmalloc(sizeof(struct page *) << get_order(size), GFP_KERNEL);
> @@ -318,11 +331,13 @@ void *dma_common_contiguous_remap(struct page *page, size_t size,
> for (i = 0, pfn = page_to_pfn(page); i < (size >> PAGE_SHIFT); i++)
> pages[i] = pfn_to_page(pfn + i);
>
> - ptr = dma_common_pages_remap(pages, size, vm_flags, prot, caller);
> + area = __dma_common_pages_remap(pages, size, vm_flags, prot, caller);
>
> kfree(pages);
>
> - return ptr;
> + if (!area)
> + return NULL;
> + return area->addr;
> }
>
> /*
>
>From a quick glance, this looks okay. I can give a proper tag when
the fix to allow mmaping comes in since I'm guessing -ENXIO is not the
end goal.
Thanks,
Laura
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Increase SMMU CMD queue poll timeout
From: Sunil Kovvuri @ 2017-04-24 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160841.GS12323@arm.com>
On Mon, Apr 24, 2017 at 9:38 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Apr 24, 2017 at 05:29:36PM +0530, Geetha sowjanya wrote:
>> From: Geetha <gakula@cavium.com>
>>
>> When large memory is being unmapped, huge no of tlb invalidation cmds are
>> submitted followed by a SYNC command. This sometimes hits CMD queue full and
>> poll on queue drain is being timedout throwing error message 'CMD_SYNC timeout'.
>>
>> Although there is no functional issue, error message confuses user. Hence increased
>> poll timeout to 500us
>
> Hmm, what are you doing to unmap that much? Is this VFIO teardown? Do you
> have 7c6d90e2bb1a ("iommu/io-pgtable-arm: Fix iova_to_phys for block
> entries") applied?
Yes it's VFIO teardown and again yes the above fix is applied.
But i didn't get how above fix is related.
TLB invalidation commands are submitted at 'arm_smmu_tlb_inv_range_nosync()'
and it's a loop over granule size.
1357 do {
1358 arm_smmu_cmdq_issue_cmd(smmu, &cmd);
1359 cmd.tlbi.addr += granule;
1360 } while (size -= granule);
So if invalidation size is big then huge no of invalidation commands
will be submitted
irrespective of fix that you pointed above, right ?
Thanks,
Sunil.
>
> Will
>
>>
>> Signed-off-by: Geetha <gakula@cavium.com>
>> ---
>> drivers/iommu/arm-smmu-v3.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 591bb96..1dcd154 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -407,7 +407,7 @@
>> #define PRIQ_1_ADDR_MASK 0xfffffffffffffUL
>>
>> /* High-level queue structures */
>> -#define ARM_SMMU_POLL_TIMEOUT_US 100
>> +#define ARM_SMMU_POLL_TIMEOUT_US 500
>>
>> #define MSI_IOVA_BASE 0x8000000
>> #define MSI_IOVA_LENGTH 0x100000
>> --
>> 1.9.1
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Maciej W. Rozycki @ 2017-04-24 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a32Y0AiKyVaotYb14uZZ1jM=nwhFD1vyP56epW1Y9KqSw@mail.gmail.com>
On Mon, 24 Apr 2017, Arnd Bergmann wrote:
> > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not
> > do it.I guess most people using old compilers know what they're doing.
>
> What I'm trying to find out first is whether "people regularly using 10+
> year old compilers for the latest kernels" is a strict subset of "people in
> Geert's household".
Well I do not live with Geert TBH.
> Given that none of the three architectures I looked at (arm, mips, x86)
> has successfully built any defconfig for a few years, it's quite possible
> that it's just you ;-) The other architectures that were around 10 years
> ago (so they might have someone who still has old toolchain binaries)
> and that still exist today are alpha, cris, frv, ia64, m32r, parisc, powerpc,
> s390, sh, sparc and xtensa. The first six are similar to m68k in that the
> hardware is mostly obsolete and the ports are kept around to support
> those old systems that might also use ancient toolchains, or new
> toolchains may be unmaintained or buggy, which could be a reason
> to keep 4.1 supported or at least try to find out if 4.1 (or even any other
> version) still works at all.
Huh?
$ git log -1
commit 5a7ad1146caa895ad718a534399e38bd2ba721b7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Apr 23 16:53:00 2017 -0700
Linux 4.11-rc8
$ /usr/bin/time make ARCH=mips CROSS_COMPILE=mipsel-linux- decstation_defconfig vmlinux >/dev/null 2>&1
1014.19user 71.47system 19:33.24elapsed 92%CPU (0avgtext+0avgdata
0maxresident)k18764inputs+242504outputs (704major+9549837minor)pagefaults 0swaps
$ mipsel-linux-gcc --version
gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$
Methinks it builds just fine.
Maciej
^ permalink raw reply
* [PATCH 1/5 v3] usb: host: add DT bindings for faraday fotg2
From: Hans Ulli Kroll @ 2017-04-24 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421204058.6206-1-linus.walleij@linaro.org>
Hi Linus
On Fri, 21 Apr 2017, Linus Walleij wrote:
> From: Hans Ulli Kroll <ulli.kroll@googlemail.com>
>
> This adds device tree bindings for the Faraday FOTG2
> dual-mode host controller.
>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v3:
> - Change compatible to "faraday,fotg210" as the name of the
> hardware block.
> - Add an elaborate SoC-specific compatible string for the
> Cortina Systems Gemini so that SoC-specific features can
> be enabled.
> - Add cortina,gemini-mini-b to indicate a Gemini PHY with
> a Mini-B adapter connected.
> - Indicated that the Gemini version can handle "wakeup-source".
> - Add optional IP block clock.
> ---
> .../devicetree/bindings/usb/faraday,fotg210.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/faraday,fotg210.txt
>
Got NAK'ed from Rob on some ealier round due missing "device mode" on this
IP. I've blatantly overrided this to a host only driver.
These are the needed changes in DT to support both modes
Note the -dr at the end of fotg210, to reflect this in an dual role device
diff --git a/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
index cf06808303e2..862cda19e9d3 100644
--- a/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
+++ b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
@@ -13,6 +13,9 @@ Required properties:
Optional properties:
- clocks: should contain the IP block clock
- clock-names: should be "PCLK" for the IP block clock
+- dr_mode : indicates the working mode for "fotg210-dr" compatible
+ controllers. Can be "host", "peripheral". Default to
+ "host" if not defined for backward compatibility.
Required properties for "cortina,gemini-usb" compatible:
- syscon: a phandle to the system controller to access PHY registers
@@ -25,7 +28,7 @@ Optional properties for "cortina,gemini-usb" compatible:
Example for Gemini:
usb at 68000000 {
- compatible = "cortina,gemini-usb", "faraday,fotg210";
+ compatible = "cortina,gemini-usb", "faraday,fotg210-dr";
reg = <0x68000000 0x1000>;
interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cc 12>;
^ 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