lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e64d7f2f-209e-cf7d-6ddc-88d338b1c010@arm.com>
Date:   Mon, 13 May 2019 10:19:52 +0100
From:   Julien Grall <julien.grall@....com>
To:     Oleksandr Tyshchenko <olekstysh@...il.com>,
        linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     horms@...ge.net.au, magnus.damm@...il.com, linux@...linux.org.uk,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
Subject: Re: [RFC PATCH] ARM: mach-shmobile: Parse DT to get ARCH timer memory
 region

Hi,

On 5/10/19 5:22 PM, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
> 
> Don't use hardcoded address, retrieve it from device-tree instead.
> 
> And besides, this patch fixes the memory error when running
> on top of Xen hypervisor:
> 
> (XEN) traps.c:1999:d0v0 HSR=0x93830007 pc=0xc0b097f8 gva=0xf0805000
>        gpa=0x000000e6080000
> 
> Which shows that VCPU0 in Dom0 is trying to access an address in memory
> it is not allowed to access (0x000000e6080000).
> Put simply, Xen doesn't know that it is a device's register memory
> since it wasn't described in a host device tree (which Xen parses)
> and as the result this memory region wasn't assigned to Dom0 at
> domain creation time.
> 
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
> 
> ---
> 
> This patch is meant to get feedback from the community before
> proceeding further. If we decide to go this direction, all Gen2
> device-trees should be updated (add memory region) before
> this patch going in.
> 
> e.g. r8a7790.dtsi:
> 
> ...
> timer {
> 	compatible = "arm,armv7-timer";
> 	interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> 			      <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> 			      <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> 			      <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
> +	 reg = <0 0xe6080000 0 0x1000>;

This looks incorrect, the "arm,armv7-timer" bindings doesn't offer you 
the possibility to specify an MMIO region. This makes sense because it 
is meant to describe the Arch timer that is only access via co-processor 
registers.

Looking at the code, I think the MMIO region corresponds to the 
coresight (based on the register name). So you may want to describe the 
coresight in the Device-Tree.

Also, AFAICT, the code is configuring and turning on the timer if it has 
not been done yet. If you are here running on Xen, then you have 
probably done something wrong. Indeed, it means Xen would not be able to 
use the timer until Dom0 has booted. But, shouldn't newer U-boot do it 
for you?

Cheers,

-- 
Julien Grall

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ