kernel.git/arch/arm64/kernel/head.S, branch linux-3.18.y

arm64: Relax GIC version check during early boot

2019-03-23T07:19:00Z

[ Upstream commit 74698f6971f25d045301139413578865fc2bd8f9 ] Updates to the GIC architecture allow ID_AA64PFR0_EL1.GIC to have values other than 0 or 1. At the moment, Linux is quite strict in the way it handles this field at early boot stage (cpufeature is fine) and will refuse to use the system register CPU interface if it doesn't find the value 1. Fixes: 021f653791ad17e03f98aaa7fb933816ae16f161 ("irqchip: gic-v3: Initial support for GICv3") Reported-by: Chase Conklin Reviewed-by: Marc Zyngier Signed-off-by: Vladimir Murzin Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

arm64: Make sure SPsel is always set

2017-10-05T07:35:52Z

commit 5371513fb338fb9989c569dc071326d369d6ade8 upstream. When the kernel is entered at EL2 on an ARMv8.0 system, we construct the EL1 pstate and make sure this uses the the EL1 stack pointer (we perform an exception return to EL1h). But if the kernel is either entered at EL1 or stays at EL2 (because we're on a VHE-capable system), we fail to set SPsel, and use whatever stack selection the higher exception level has choosen for us. Let's not take any chance, and make sure that SPsel is set to one before we decide the mode we're going to run in. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman

arm64: head.S: initialise mdcr_el2 in el2_setup

2015-10-07T14:05:15Z

[ Upstream commit d10bcd473301888f957ec4b6b12aa3621be78d59 ] When entering the kernel at EL2, we fail to initialise the MDCR_EL2 register which controls debug access and PMU capabilities at EL1. This patch ensures that the register is initialised so that all traps are disabled and all the PMU counters are available to the host. When a guest is scheduled, KVM takes care to configure trapping appropriately. Cc: Acked-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text

2014-09-08T13:39:18Z

The static memory footprint of a kernel Image at boot is larger than the Image file itself. Things like .bss data and initial page tables are allocated statically but populated dynamically so their content is not contained in the Image file. However, if EFI (or GRUB) has loaded the Image at precisely the desired offset of base of DRAM + TEXT_OFFSET, the Image will be booted in place, and we have to make sure that the allocation done by the PE/COFF loader is large enough. Fix this by growing the PE/COFF .text section to cover the entire static memory footprint. The part of the section that is not covered by the payload will be zero initialised by the PE/COFF loader. Acked-by: Mark Salter Acked-by: Mark Rutland Acked-by: Leif Lindholm Tested-by: Leif Lindholm Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon

arm64: Remove unused variable in head.S

2014-08-26T18:24:00Z

Remove an unused local variable from head.S. It seems this was never used even from the initial commit 9703d9d7f77ce129621f7d80a844822e2daa7008 (arm64: Kernel booting and initialisation), and is a left over from a previous implementation of __calc_phys_offset. Signed-off-by: Geoff Levand Signed-off-by: Will Deacon

arm64: align randomized TEXT_OFFSET on 4 kB boundary

2014-08-19T18:26:09Z

When booting via UEFI, the kernel Image is loaded at a 4 kB boundary and the embedded EFI stub is executed in place. The EFI stub relocates the Image to reside TEXT_OFFSET bytes above a 2 MB boundary, and jumps into the kernel proper. In AArch64, PC relative symbol references are emitted using adrp/add or adrp/ldr pairs, where the offset into a 4 kB page is resolved using a separate :lo12: relocation. This implicitly assumes that the code will always be executed at the same relative offset with respect to a 4 kB boundary, or the references will point to the wrong address. This means we should link the kernel at a 4 kB aligned base address in order to remain compatible with the base address the UEFI loader uses when doing the initial load of Image. So update the code that generates TEXT_OFFSET to choose a multiple of 4 kB. At the same time, update the code so it chooses from the interval [0..2MB) as the author originally intended. Reviewed-by: Mark Rutland Signed-off-by: Ard Biesheuvel Signed-off-by: Will Deacon

arm64: gicv3: Allow GICv3 compilation with older binutils

2014-07-25T12:12:15Z

GICv3 introduces new system registers accessible with the full msr/mrs syntax (e.g. mrs x0, Sop0_op1_CRm_CRn_op2). However, only recent binutils understand the new syntax. This patch introduces msr_s/mrs_s assembly macros which generate the equivalent instructions above and converts the existing GICv3 code (both drivers/irqchip/ and arch/arm64/kernel/). Signed-off-by: Catalin Marinas Reported-by: Olof Johansson Tested-by: Olof Johansson Suggested-by: Mark Rutland Acked-by: Mark Rutland Acked-by: Jason Cooper Cc: Will Deacon Cc: Marc Zyngier

Merge tag 'deps-irqchip-gic-3.17' of git://git.infradead.org/users/jcooper/linux

2014-07-25T12:03:22Z

* tag 'deps-irqchip-gic-3.17' of git://git.infradead.org/users/jcooper/linux: irqchip: gic-v3: Initial support for GICv3 irqchip: gic: Move some bits of GICv2 to a library-type file Conflicts: arch/arm64/Kconfig

arm64: Add support for 48-bit VA space with 64KB page configuration

2014-07-23T14:28:15Z

This patch allows support for 3 levels of page tables with 64KB page configuration allowing 48-bit VA space. The pgd is no longer a full PAGE_SIZE (PTRS_PER_PGD is 64) and (swapper|idmap)_pg_dir are not fully populated (pgd_alloc falls back to kzalloc). Signed-off-by: Catalin Marinas Tested-by: Jungseok Lee

arm64: Clean up the initial page table creation in head.S

2014-07-23T14:28:01Z

This patch adds a create_table_entry macro which is used to populate pgd and pud entries, also reducing the number of arguments for create_pgd_entry. Signed-off-by: Catalin Marinas Tested-by: Jungseok Lee