<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/arm64/kernel/asm-offsets.c, branch linux-4.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-05-31T13:48:23Z</updated>
<entry>
<title>arm64: vdso: Fix clock_getres() for CLOCK_REALTIME</title>
<updated>2019-05-31T13:48:23Z</updated>
<author>
<name>Vincenzo Frascino</name>
</author>
<published>2019-04-16T16:14:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9f641ee2b749d57b4672e4c28f4dba9523923ac4'/>
<id>urn:sha1:9f641ee2b749d57b4672e4c28f4dba9523923ac4</id>
<content type='text'>
[ Upstream commit 81fb8736dd81da3fe94f28968dac60f392ec6746 ]

clock_getres() in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().

In particular, posix_get_hrtimer_res() does:

    sec = 0;
    ns = hrtimer_resolution;

where 'hrtimer_resolution' depends on whether or not high resolution
timers are enabled, which is a runtime decision.

The vDSO incorrectly returns the constant CLOCK_REALTIME_RES. Fix this
by exposing 'hrtimer_resolution' in the vDSO datapage and returning that
instead.

Reviewed-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
[will: Use WRITE_ONCE(), move adr off COARSE path, renumber labels, use 'w' reg]
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: KVM: Handle guest's ARCH_WORKAROUND_2 requests</title>
<updated>2018-07-22T12:27:42Z</updated>
<author>
<name>Marc Zyngier</name>
</author>
<published>2018-07-20T09:56:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f99e40649147bb49e6dc7c1ce748617363c51434'/>
<id>urn:sha1:f99e40649147bb49e6dc7c1ce748617363c51434</id>
<content type='text'>
commit b4f18c063a13dfb33e3a63fe1844823e19c2265e upstream.

In order to forward the guest's ARCH_WORKAROUND_2 calls to EL3,
add a small(-ish) sequence to handle it at EL2. Special care must
be taken to track the state of the guest itself by updating the
workaround flags. We also rely on patching to enable calls into
the firmware.

Note that since we need to execute branches, this always executes
after the Spectre-v2 mitigation has been applied.

Reviewed-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Avoid storing the vcpu pointer on the stack</title>
<updated>2018-07-22T12:27:41Z</updated>
<author>
<name>Christoffer Dall</name>
</author>
<published>2018-07-20T09:56:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cab367c1c9b7797d7747a523935a90dc05ff24a1'/>
<id>urn:sha1:cab367c1c9b7797d7747a523935a90dc05ff24a1</id>
<content type='text'>
Commit 4464e210de9e80e38de59df052fe09ea2ff80b1b upstream.

We already have the percpu area for the host cpu state, which points to
the VCPU, so there's no need to store the VCPU pointer on the stack on
every context switch.  We can be a little more clever and just use
tpidr_el2 for the percpu offset and load the VCPU pointer from the host
context.

This has the benefit of being able to retrieve the host context even
when our stack is corrupted, and it has a potential performance benefit
because we trade a store plus a load for an mrs and a load on a round
trip to the guest.

This does require us to calculate the percpu offset without including
the offset from the kernel mapping of the percpu array to the linear
mapping of the array (which is what we store in tpidr_el1), because a
PC-relative generated address in EL2 is already giving us the hyp alias
of the linear mapping of a kernel address.  We do this in
__cpu_init_hyp_mode() by using kvm_ksym_ref().

The code that accesses ESR_EL2 was previously using an alternative to
use the _EL1 accessor on VHE systems, but this was actually unnecessary
as the _EL1 accessor aliases the ESR_EL2 register on VHE, and the _EL2
accessor does the same thing on both systems.

Cc: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Reviewed-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Reviewed-by: Andrew Jones &lt;drjones@redhat.com&gt;
Signed-off-by: Christoffer Dall &lt;christoffer.dall@linaro.org&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>arm64: mm: Map entry trampoline into trampoline and kernel page tables</title>
<updated>2018-04-08T10:12:52Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2018-04-03T11:09:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1809afd71b9c419ab8b57c3ea5c870b5285f442a'/>
<id>urn:sha1:1809afd71b9c419ab8b57c3ea5c870b5285f442a</id>
<content type='text'>
commit 51a0048beb44 upstream.

The exception entry trampoline needs to be mapped at the same virtual
address in both the trampoline page table (which maps nothing else)
and also the kernel page table, so that we can swizzle TTBR1_EL1 on
exceptions from and return to EL0.

This patch maps the trampoline at a fixed virtual address in the fixmap
area of the kernel virtual address space, which allows the kernel proper
to be randomized with respect to the trampoline when KASLR is enabled.

Reviewed-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Tested-by: Laura Abbott &lt;labbott@redhat.com&gt;
Tested-by: Shanker Donthineni &lt;shankerd@codeaurora.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Alex Shi &lt;alex.shi@linaro.org&gt;
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt; [v4.9 backport]
Tested-by: Will Deacon &lt;will.deacon@arm.com&gt;
Tested-by: Greg Hackmann &lt;ghackmann@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>arm: kernel: Add SMC structure parameter</title>
<updated>2017-04-12T10:41:21Z</updated>
<author>
<name>Andy Gross</name>
</author>
<published>2017-04-04T19:32:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=007f0a2f2c0fcfa9ecef016c0910aebd0b784fdd'/>
<id>urn:sha1:007f0a2f2c0fcfa9ecef016c0910aebd0b784fdd</id>
<content type='text'>
[ Upstream commit 680a0873e193bae666439f4b5e32c758e68f114c ]

This patch adds a quirk parameter to the arm_smccc_(smc/hvc) calls.
The quirk structure allows for specialized SMC operations due to SoC
specific requirements.  The current arm_smccc_(smc/hvc) is renamed and
macros are used instead to specify the standard arm_smccc_(smc/hvc) or
the arm_smccc_(smc/hvc)_quirk function.

This patch and partial implementation was suggested by Will Deacon.

Signed-off-by: Andy Gross &lt;andy.gross@linaro.org&gt;
Reviewed-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>arm64: Work around systems with mismatched cache line sizes</title>
<updated>2016-09-09T14:03:29Z</updated>
<author>
<name>Suzuki K Poulose</name>
</author>
<published>2016-09-09T13:07:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=116c81f427ff6c5380850963e3fb8798cc821d2b'/>
<id>urn:sha1:116c81f427ff6c5380850963e3fb8798cc821d2b</id>
<content type='text'>
Systems with differing CPU i-cache/d-cache line sizes can cause
problems with the cache management by software when the execution
is migrated from one to another. Usually, the application reads
the cache size on a CPU and then uses that length to perform cache
operations. However, if it gets migrated to another CPU with a smaller
cache line size, things could go completely wrong. To prevent such
cases, always use the smallest cache line size among the CPUs. The
kernel CPU feature infrastructure already keeps track of the safe
value for all CPUID registers including CTR. This patch works around
the problem by :

For kernel, dynamically patch the kernel to read the cache size
from the system wide copy of CTR_EL0.

For applications, trap read accesses to CTR_EL0 (by clearing the SCTLR.UCT)
and emulate the mrs instruction to return the system wide safe value
of CTR_EL0.

For faster access (i.e, avoiding to lookup the system wide value of CTR_EL0
via read_system_reg), we keep track of the pointer to table entry for
CTR_EL0 in the CPU feature infrastructure.

Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Andre Przywara &lt;andre.przywara@arm.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Suzuki K Poulose &lt;suzuki.poulose@arm.com&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux</title>
<updated>2016-07-27T18:16:05Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2016-07-27T18:16:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e831101a73fbc8339ef1d1909dad3ef64f089e70'/>
<id>urn:sha1:e831101a73fbc8339ef1d1909dad3ef64f089e70</id>
<content type='text'>
Pull arm64 updates from Catalin Marinas:

 - Kexec support for arm64

 - Kprobes support

 - Expose MIDR_EL1 and REVIDR_EL1 CPU identification registers to sysfs

 - Trapping of user space cache maintenance operations and emulation in
   the kernel (CPU errata workaround)

 - Clean-up of the early page tables creation (kernel linear mapping,
   EFI run-time maps) to avoid splitting larger blocks (e.g.  pmds) into
   smaller ones (e.g.  ptes)

 - VDSO support for CLOCK_MONOTONIC_RAW in clock_gettime()

 - ARCH_HAS_KCOV enabled for arm64

 - Optimise IP checksum helpers

 - SWIOTLB optimisation to only allocate/initialise the buffer if the
   available RAM is beyond the 32-bit mask

 - Properly handle the "nosmp" command line argument

 - Fix for the initialisation of the CPU debug state during early boot

 - vdso-offsets.h build dependency workaround

 - Build fix when RANDOMIZE_BASE is enabled with MODULES off

* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (64 commits)
  arm64: arm: Fix-up the removal of the arm64 regs_query_register_name() prototype
  arm64: Only select ARM64_MODULE_PLTS if MODULES=y
  arm64: mm: run pgtable_page_ctor() on non-swapper translation table pages
  arm64: mm: make create_mapping_late() non-allocating
  arm64: Honor nosmp kernel command line option
  arm64: Fix incorrect per-cpu usage for boot CPU
  arm64: kprobes: Add KASAN instrumentation around stack accesses
  arm64: kprobes: Cleanup jprobe_return
  arm64: kprobes: Fix overflow when saving stack
  arm64: kprobes: WARN if attempting to step with PSTATE.D=1
  arm64: debug: remove unused local_dbg_{enable, disable} macros
  arm64: debug: remove redundant spsr manipulation
  arm64: debug: unmask PSTATE.D earlier
  arm64: localise Image objcopy flags
  arm64: ptrace: remove extra define for CPSR's E bit
  kprobes: Add arm64 case in kprobe example module
  arm64: Add kernel return probes support (kretprobes)
  arm64: Add trampoline code for kretprobes
  arm64: kprobes instruction simulation support
  arm64: Treat all entry code as non-kprobe-able
  ...
</content>
</entry>
<entry>
<title>Merge branch 'for-next/kprobes' into for-next/core</title>
<updated>2016-07-21T17:20:41Z</updated>
<author>
<name>Catalin Marinas</name>
</author>
<published>2016-07-21T17:20:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a95b0644b38c16c40b753224671b919b9af0b73c'/>
<id>urn:sha1:a95b0644b38c16c40b753224671b919b9af0b73c</id>
<content type='text'>
* kprobes:
  arm64: kprobes: Add KASAN instrumentation around stack accesses
  arm64: kprobes: Cleanup jprobe_return
  arm64: kprobes: Fix overflow when saving stack
  arm64: kprobes: WARN if attempting to step with PSTATE.D=1
  kprobes: Add arm64 case in kprobe example module
  arm64: Add kernel return probes support (kretprobes)
  arm64: Add trampoline code for kretprobes
  arm64: kprobes instruction simulation support
  arm64: Treat all entry code as non-kprobe-able
  arm64: Blacklist non-kprobe-able symbol
  arm64: Kprobes with single stepping support
  arm64: add conditional instruction simulation support
  arm64: Add more test functions to insn.c
  arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
</content>
</entry>
<entry>
<title>arm64: Add trampoline code for kretprobes</title>
<updated>2016-07-19T14:03:22Z</updated>
<author>
<name>William Cohen</name>
</author>
<published>2016-07-08T16:35:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=da6a91252ad98d49b49e83b76c1f032cdf6e5258'/>
<id>urn:sha1:da6a91252ad98d49b49e83b76c1f032cdf6e5258</id>
<content type='text'>
The trampoline code is used by kretprobes to capture a return from a probed
function.  This is done by saving the registers, calling the handler, and
restoring the registers. The code then returns to the original saved caller
return address. It is necessary to do this directly instead of using a
software breakpoint because the code used in processing that breakpoint
could itself be kprobe'd and cause a problematic reentry into the debug
exception handler.

Signed-off-by: William Cohen &lt;wcohen@redhat.com&gt;
Signed-off-by: David A. Long &lt;dave.long@linaro.org&gt;
Acked-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
[catalin.marinas@arm.com: removed unnecessary masking of the PSTATE bits]
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: Add support for CLOCK_MONOTONIC_RAW in clock_gettime() vDSO</title>
<updated>2016-07-12T15:06:32Z</updated>
<author>
<name>Kevin Brodsky</name>
</author>
<published>2016-07-12T10:24:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=49eea433b326a0ac5c7c941a011b2c65990bd19b'/>
<id>urn:sha1:49eea433b326a0ac5c7c941a011b2c65990bd19b</id>
<content type='text'>
So far the arm64 clock_gettime() vDSO implementation only supported
the following clocks, falling back to the syscall for the others:
- CLOCK_REALTIME{,_COARSE}
- CLOCK_MONOTONIC{,_COARSE}

This patch adds support for the CLOCK_MONOTONIC_RAW clock, taking
advantage of the recent refactoring of the vDSO time functions. Like
the non-_COARSE clocks, this only works when the "arch_sys_counter"
clocksource is in use (allowing us to read the current time from the
virtual counter register), otherwise we also have to fall back to the
syscall.

Most of the data is shared with CLOCK_MONOTONIC, and the algorithm is
similar. The reference implementation in kernel/time/timekeeping.c
shows that:
- CLOCK_MONOTONIC = tk-&gt;wall_to_monotonic + tk-&gt;xtime_sec +
  timekeeping_get_ns(&amp;tk-&gt;tkr_mono)
- CLOCK_MONOTONIC_RAW = tk-&gt;raw_time + timekeeping_get_ns(&amp;tk-&gt;tkr_raw)
- tkr_mono and tkr_raw are identical (in particular, same
  clocksource), except these members:
  * mult (only mono's multiplier is NTP-adjusted)
  * xtime_nsec (always 0 for raw)

Therefore, tk-&gt;raw_time and tkr_raw-&gt;mult are now also stored in the
vDSO data page.

Cc: Ali Saidi &lt;ali.saidi@arm.com&gt;
Signed-off-by: Kevin Brodsky &lt;kevin.brodsky@arm.com&gt;
Reviewed-by: Dave Martin &lt;dave.martin@arm.com&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
</feed>
