"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Sun Jul 24 20:28:32 UTC 2022
>
> Modified Files:
> src/sys/arch/aarch64/include: lock.h
>
> Log Message:
> aarch64/lock.h: Need for _HARDKERNEL.
>
> Add include guard while here.
>
> XXX Why does this a
On Mon, 22 Feb 2021, Ryo Shimizu wrote:
I think this condition is not necessary since cpu_idle() is just called from
idle_loop(),
and ci_intr_depth is always zero at this time.
Ah yes, my mistake! Please feel free to revert this commit as part of
your proposed change.
> On Feb 22, 2021, at 11:49 AM, Ryo Shimizu wrote:
>
> Ah, You are quite right!
> idle/# lwp is provided and assigned for each CPU, so curcpu() obtained from
> idle lwp was always the same.
> So, there's no need to move curcpu() to after DISABLE_INTERRUPT.
Please make sure to add a comment exp
>> In addition, because of the possibility of kpreemption (but aarch64 has =
>no KPREEMPT yet),
>> the acquisition of curcpu() is moved to after DISABLE_INTERRUPT and got =
>the following.
>>
>[snip]
>
>
>>
>> Is this ok?
>>
>
>Looks good - I wonder if the fact that curcpu is an invariant for the
On 22/02/2021 10:40, Ryo Shimizu wrote:
Module Name:src
Committed By: jmcneill
Date: Sun Feb 21 23:37:10 UTC 2021
Modified Files:
src/sys/arch/aarch64/aarch64: idle_machdep.S
Log Message:
When waking from cpu_idle(), only call dosoftints if ci_intr_depth == 0
To gene
>Module Name: src
>Committed By: jmcneill
>Date: Sun Feb 21 23:37:10 UTC 2021
>
>Modified Files:
> src/sys/arch/aarch64/aarch64: idle_machdep.S
>
>Log Message:
>When waking from cpu_idle(), only call dosoftints if ci_intr_depth == 0
>
>
>To generate a diff of this commit:
>cvs r
> Log Message:
> Fix build as crash(8); Protect db_md_meminfo_cmd() by defined(_KERNEL).
thanks. surprised i never saw this as the change was in a
tree for a few weeks, but i guess i was mostly doing kernels
in that tree not full builds..
.mrg.
On Tue, Oct 13, 2020 at 12:57:44PM +0200, Kamil Rytarowski wrote:
> > Log Message:
> > BE32 binaries are no longer supported for ARMv7 and later, and
> > therefore for aarch64eb.
> >
> > Reject them with ENOEXEC, rather than causing illegal instruction
> > exceptions due to unexpected binary forma
On 2020/10/13 19:57, Kamil Rytarowski wrote:
On 13.10.2020 09:04, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Oct 13 07:04:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: exec_machdep.c
Log Message:
BE32 binaries are no longer supported for
On 13.10.2020 09:04, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 13 07:04:49 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: exec_machdep.c
>
> Log Message:
> BE32 binaries are no longer supported for ARMv7 and later, and
> therefore for a
It works fine now. Thank you for quick fix!!
rin
On 2020/10/06 15:28, Nick Hudson wrote:
On 06/10/2020 01:54, Rin Okuyama wrote:
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/
On 06/10/2020 01:54, Rin Okuyama wrote:
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S
Log Message:
Move el[01]_trap_exit into vectors.S w
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S
Log Message:
Move el[01]_trap_exit into vectors.S where the callers exist
To generate
>> Index: src/sys/arch/aarch64/include/cpu.h
>> diff -u src/sys/arch/aarch64/include/cpu.h:1.27 src/sys/arch/aarch64/inc=
>lude/cpu.h:1.28
>> --- src/sys/arch/aarch64/include/cpu.h:1.27 Mon Sep 14 10:06:35 2020
>> +++ src/sys/arch/aarch64/include/cpu.h Thu Oct 1 06:40:16 2020
>> @@ -1,4 +1,
On 01/10/2020 07:40, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Thu Oct 1 06:40:16 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: procfs_machdep.c
src/sys/arch/aarch64/include: cpu.h
Log Message:
fix build error with LLVM
[...]
Index:
>On 24/09/2020 10:04, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Thu Sep 24 09:04:38 UTC 2020
>>
>> Modified Files:
>> src/sys/arch/aarch64/aarch64: bus_space_asm_generic.S
>>
>> Log Message:
>> fix bugs in *_bs_rm_8_swap(). it was only reading
On 24/09/2020 10:04, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Thu Sep 24 09:04:38 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: bus_space_asm_generic.S
Log Message:
fix bugs in *_bs_rm_8_swap(). it was only reading 4 bytes, not 8 bytes.
I thi
I think this will have issues on some big.LITTLE configurations
like Rockchip RK3399.
In the RK3399 case cpu[0-3] is VIPT I$ and cpu[4-5] is PIPT I$. Boot
order of secondaries is not guaranteed so it is possible to get different
values of aarch64_cache_vindexsize from one boot to the next.
J
>> Has any consideration be given to perhaps creating a new MACHINE_ARCH for
>> this, or somehow otherwise decorating the ELF files to indicate their
>> exec-ability?
>
>I am under the impression that PAC was designed to be forewards
>compatible, so older CPUs can execute code with this annotat
On Sat, May 23, 2020 at 02:13:46PM -0700, Jason Thorpe wrote:
>
> > On May 23, 2020, at 11:08 AM, Ryo Shimizu wrote:
> >
> > Module Name:src
> > Committed By: ryo
> > Date: Sat May 23 18:08:59 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/aarch64/aarch64: cpu
> On May 23, 2020, at 11:08 AM, Ryo Shimizu wrote:
>
> Module Name: src
> Committed By: ryo
> Date: Sat May 23 18:08:59 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: cpufunc.c cpuswitch.S exec_machdep.c
> genassym.cf netbsd32_machdep.c vectors.S vm_machd
Le 28/01/2020 à 19:39, Nick Hudson a écrit :
> On 28/01/2020 17:47, Maxime Villard wrote:
>> @@ -460,8 +460,7 @@ cpu_setup_id(struct cpu_info *ci)
>>
>> id->ac_aa64mmfr0 = reg_id_aa64mmfr0_el1_read();
>> id->ac_aa64mmfr1 = reg_id_aa64mmfr1_el1_read();
>> - /* Only in ARMv8.2. */
>> -
On 30/01/2020 10:04, Maxime Villard wrote:
Le 28/01/2020 à 19:39, Nick Hudson a écrit :
On 28/01/2020 17:47, Maxime Villard wrote:
@@ -460,8 +460,7 @@ cpu_setup_id(struct cpu_info *ci)
id->ac_aa64mmfr0 = reg_id_aa64mmfr0_el1_read();
id->ac_aa64mmfr1 = reg_id_aa64mmfr1_el1_read
On 28/01/2020 17:47, Maxime Villard wrote:
@@ -460,8 +460,7 @@ cpu_setup_id(struct cpu_info *ci)
id->ac_aa64mmfr0 = reg_id_aa64mmfr0_el1_read();
id->ac_aa64mmfr1 = reg_id_aa64mmfr1_el1_read();
- /* Only in ARMv8.2. */
- id->ac_aa64mmfr2 = 0 /* reg_id_aa64mmfr2_el1_rea
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Tue Nov 20 20:53:50 UTC 2018
>
> Modified Files:
> src/sys/arch/aarch64/include: pmap.h
>
> Log Message:
> Implement PMAP_DIRECT / pmap_direct_process() in support of experimental
> UBC optimizations (com
"Ryo Shimizu" writes:
> Module Name: src
> Committed By: ryo
> Date: Wed Oct 31 06:36:19 UTC 2018
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: pmap.c
>
> Log Message:
> invalidate icache correctly.
> l3pte_executable() should be used for only valid pte.
thanks! this makes
>> Module Name: src
>> Committed By:ryo
>> Date:Mon Sep 17 00:15:55 UTC 2018
>>
>> Modified Files:
>> src/sys/arch/aarch64/aarch64: pmap.c
>>
>> Log Message:
>> delete debug printf and KASSERT.
>
>i'm confused by this (moved) comment:
>
>/* pte is readable and writ
"Ryo Shimizu" writes:
> Module Name: src
> Committed By: ryo
> Date: Mon Sep 17 00:15:55 UTC 2018
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: pmap.c
>
> Log Message:
> delete debug printf and KASSERT.
i'm confused by this (moved) comment:
/* pte is readable and writable,
On 2018/09/10 16:49, Nick Hudson wrote:
For the record this should be fixed now with
sys/arch/aarch64/aarch64/locore.S:1.24
sys/arch/evbarm/fdt/fdt_start.S:1.4
The problem is gone. Thank you for quick fix!
rin
On 10/09/18 04:41, Rin Okuyama wrote:
Hi,
Hi,
After this commit, GENERIC64 does not boot anymore on RPI3B and 3B+.
It successfully boots if locore.S is reverted to rev. 1.21.
Strangely enough, after boot with old locore.S, it can reboot with new
locore.S. However, for initial boot after power-
Hi,
Hi,
After this commit, GENERIC64 does not boot anymore on RPI3B and 3B+.
It successfully boots if locore.S is reverted to rev. 1.21.
Strangely enough, after boot with old locore.S, it can reboot with new
locore.S. However, for initial boot after power-on, only kernel with
old locore.S works
Le 08/08/2018 à 20:13, Ryo Shimizu a écrit :
It would be nice to set SCTLR_EL1.WXN, by the way.
Yes, It is easy. But should this be synchronized with
security.pax.mprotect.enabled? If so, we need a md-hook in the sysctl helper
of pax.mprotect.enable.
Ah, I misunderstood the meaning of SCTLR_E
>Also, why don't we tag each userland page with LX_BLKPAG_PXN?
Oh... I overlooked that.
Certainly, no userland page should not be set executable for kernel. I'll fix.
>It would be nice to set SCTLR_EL1.WXN, by the way.
Yes, It is easy. But should this be synchronized with
security.pax.mprote
Le 04/08/2018 à 17:24, Ryo Shimizu a écrit :
Maybe we should just pass the protection bits in l2_setblocks, and map the
kernel text/rodata as RO right away. It would also make it possible to map
rodata/data as non executable, with PXN|UXN. (Looking at the code it seems
to me rodata/data are execu
> On Aug 5, 2018, at 1:55 AM, Martin Husemann wrote:
>
> On Sat, Aug 04, 2018 at 06:33:20AM -0700, Jason Thorpe wrote:
>> It only matters when setting / removing breakpoints, so it seems like
>> you want to defer changing page protection right until then.
>
> Can't we do the breakpoint change
On Sat, Aug 04, 2018 at 06:33:20AM -0700, Jason Thorpe wrote:
> It only matters when setting / removing breakpoints, so it seems like
> you want to defer changing page protection right until then.
Can't we do the breakpoint changes via the direct map instead?
Martin
> On Aug 4, 2018, at 2:09 AM, Maxime Villard wrote:
>
> Regarding the DDB ifndef, probably there must be
> a bit in ARM64 saying "disable page protection", so it could be set when
> we enter DDB, and we could remove the ifndef.
It only matters when setting / removing breakpoints, so it seems
>Maybe we should just pass the protection bits in l2_setblocks, and map the
>kernel text/rodata as RO right away. It would also make it possible to map
>rodata/data as non executable, with PXN|UXN. (Looking at the code it seems
>to me rodata/data are executable currently.)
>
>We would make three
Module Name:src
Committed By: ryo
Date: Fri Aug 3 16:32:55 UTC 2018
Modified Files:
src/sys/arch/aarch64/aarch64: genassym.cf locore.S
src/sys/arch/aarch64/conf: kern.ldscript
Log Message:
set kernel text/rodata readonly when not defined DDB.
set readonly segment
On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
| kern_vtopdiff has already been fixed. (thanks christos@)
| u_int uboot_args[4] (in various file :-P) has same problem.
| Should I fix it? [Y/y]
I just did.
christos
On Jul 18, 12:57am, r...@nerv.org (Ryo Shimizu) wrote:
-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
|
| >On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
| >-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
| >
| >| kern_vtopdiff has already been fixed. (tha
>On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
>-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
>
>| kern_vtopdiff has already been fixed. (thanks christos@)
>| u_int uboot_args[4] (in various file :-P) has same problem.
>| Should I fix it? [Y/y]
>
>
On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
| kern_vtopdiff has already been fixed. (thanks christos@)
| u_int uboot_args[4] (in various file :-P) has same problem.
| Should I fix it? [Y/y]
Please do! Does the gcc kernel boot
>On Tue, Jul 17, 2018 at 11:12:41AM +, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Tue Jul 17 11:12:41 UTC 2018
>>
>> Modified Files:
>> src/sys/arch/aarch64/aarch64: aarch64_machdep.c
>>
>> Log Message:
>> kern_vtopdiff is stored in fdt_s
In article <2018071711.5b119f...@cvs.netbsd.org>,
Joerg Sonnenberger wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: joerg
>Date: Tue Jul 17 11:55:55 UTC 2018
>
>Modified Files:
> src/sys/arch/aarch64/include: types.h
>
>Log Message:
>Be consistent and explicitly size
On Tue, Jul 17, 2018 at 11:12:41AM +, Ryo Shimizu wrote:
> Module Name: src
> Committed By: ryo
> Date: Tue Jul 17 11:12:41 UTC 2018
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: aarch64_machdep.c
>
> Log Message:
> kern_vtopdiff is stored in fdt_start.S. that is before c
46 matches
Mail list logo