On Sat, 24 Dec 2022 at 13:19, Marc Zyngier wrote:
>
> On Thu, 22 Dec 2022 13:01:55 +0000,
> Ard Biesheuvel wrote:
> >
> > On Tue, 20 Dec 2022 at 21:09, Marc Zyngier wrote:
> > >
> > > A recent development on the EFI front has resulted in guests havi
;) do we end-up
> with two back-to-back faults (page being evicted and faulted back).
> I don't think this is a case worth optimising for.
>
> Fixes: c4ad98e4b72c ("KVM: arm64: Assume write fault on S1PTW permission
> fault on instruction fetch")
> Signed-off-by:
references, but this is no longer the case, so
we can simply use relative addressing instead. This removes a couple of
RELA entries pointing into the .text segment.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/kvm/hyp/nvhe/host.S | 8 +++-
1 file changed, 3 insertions(+), 5 deletions
On Fri, 25 Feb 2022 at 03:12, Chen, Rong A wrote:
>
>
>
> Hi Marc, Ard,
>
> We have ignored the warning related to asmlinkage according to the below
> advice:
>
> https://lore.kernel.org/lkml/CAMj1kXHrRYagSVniSetHdG15rkQS+fm4zVOtN=zda3w0qae...@mail.gmail.com/
>
Excellent! Thanks for implementing
On Wed, 23 Feb 2022 at 13:54, Marc Zyngier wrote:
>
> On 2022-02-23 12:34, Philip Li wrote:
> > On Wed, Feb 23, 2022 at 09:16:59AM +, Marc Zyngier wrote:
> >> On Wed, 23 Feb 2022 09:05:18 +,
> >> kernel test robot wrote:
> >> >
> >> > Hi Kalesh,
> >> >
> >> > Thank you for the patch! Perh
userspace (only
> KVM will have a bit more work tracking the EOI), but at least
> this is correct.
>
> Reported-by: Pierre Gondois
> Signed-off-by: Marc Zyngier
> Cc: Ard Biesheuvel
> Cc: Sami Mujawar
> Cc: Will Deacon
Acked-by: Ard Biesheuvel
> ---
> p
Switch to set_pte_at() so we can provide the mm pointer to the code that
performs the page table update.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/mm/hugetlbpage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm
The set_pte() helper does not carry the struct mm pointer, which makes
it difficult for the implementation to reason about the context in which
the set_pte() call is taking place. So switch to set_pte_at() instead.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/kernel/efi.c | 2 +-
1 file changed
Implement a default version of p4d_index() similar to how pud/pmd_index
are defined.
Signed-off-by: Ard Biesheuvel
---
include/linux/pgtable.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index bc8713a76e03..e8aacf6ea207 100644
Now that all the handling is in place to deal with read-only page tables
at runtime, do a pass over the kernel page tables at boot to remap all
the page table pages read-only that were allocated early.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/mm/mmu.c | 20
1 file
Now that all kernel page table manipulations are routed through the
fixmap API if r/o page tables are enabled, we can remove write access
from the linear mapping of those pages.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/pgalloc.h | 6 +
arch/arm64/mm/mmu.c | 24
Now that all PTE manipulations for user space tables go via the fixmap,
we can remap these tables read-only in the linear region so they cannot
be corrupted inadvertently.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/pgalloc.h | 5 +
arch/arm64/include/asm/tlb.h | 2
PMD modifications all go through the fixmap update routine, so there is
no longer a need to keep it mapped read/write in the linear region.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/pgalloc.h | 5 +
arch/arm64/include/asm/tlb.h | 2 ++
arch/arm64/mm/mmu.c
Implement the arch specific PUD alloc/free helpers by wrapping the
generic code, and remapping the page read-only on allocation and
read-write on free.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/pgalloc.h | 5 +
arch/arm64/include/asm/tlb.h | 2 ++
arch/arm64/mm/mmu.c
As the first step in restricting write access to all page tables via the
linear mapping, remap the page at the root PGD level of a user space
page table hierarchy read-only after allocation, so that it can only be
manipulated using the dedicated fixmap based API.
Signed-off-by: Ard Biesheuvel
their kernel mapping in .bss, so there is no special
exception required to avoid circular logic here.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/Kconfig | 11 +++
arch/arm64/include/asm/fixmap.h | 1 +
arch/arm64/include/asm/pgalloc.h | 28 +-
arch/arm64/include/asm
: Ard Biesheuvel
---
arch/arm64/include/asm/pgtable.h | 3 +++
arch/arm64/mm/pageattr.c | 14 ++
2 files changed, 17 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index c4ba047a82d2..8d3806c68687 100644
--- a/arch/arm64/include
cific changes will be posted as a followup series.
Cc: Will Deacon
Cc: Marc Zyngier
Cc: Fuad Tabba
Cc: Quentin Perret
Cc: Mark Rutland
Cc: James Morse
Cc: Catalin Marinas
Ard Biesheuvel (12):
asm-generic/pgalloc: allow arch to override PMD alloc/free routines
arm64: mm: add helpers to remap
Extend the existing CPP macro based hooks that allow architectures to
specialize the code that allocates and frees pages to be used as page
tables.
Signed-off-by: Ard Biesheuvel
---
include/asm-generic/pgalloc.h | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a
; an obviously broken way.
>
> So instead of imposing the M1 workaround on an innocent bystander,
> let's limit it to the two known broken Apple implementations.
>
> Fixes: df652bcf1136 ("KVM: arm64: vgic-v3: Work around GICv3 locally
> generated SErrors")
> Reported-b
On Tue, 21 Sept 2021 at 21:45, Rob Herring wrote:
>
> On Sun, Sep 5, 2021 at 11:16 PM Gavin Shan wrote:
> >
> > The empty memory nodes, where no memory resides in, are allowed.
> > For these empty memory nodes, the 'len' of 'reg' property is zero.
> > The NUMA node IDs are still valid and parsed,
On Wed, 12 May 2021 at 09:34, Mike Rapoport wrote:
>
> On Wed, May 12, 2021 at 09:00:02AM +0200, Ard Biesheuvel wrote:
> > On Tue, 11 May 2021 at 12:05, Mike Rapoport wrote:
> > >
> > > From: Mike Rapoport
> > >
> > > Hi,
> > >
&
On Tue, 11 May 2021 at 12:05, Mike Rapoport wrote:
>
> From: Mike Rapoport
>
> Hi,
>
> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> pfn_valid_within() to 1.
>
> The idea is to mark NOMAP pages as reserved in the memory map and restore
> the intended semantics of pfn
_valid() can be slightly simplified by replacing
> memblock_is_map_memory() with memblock_is_memory().
>
> Signed-off-by: Mike Rapoport
> Acked-by: David Hildenbrand
Acked-by: Ard Biesheuvel
... and many thanks for cleaning this up.
> ---
> arch/arm64/Kconfig | 3 ---
> arch/
;
> While here also update style of pfn_valid() so that both pfn_valid() and
> pfn_is_map_memory() declarations will be consistent.
>
> Signed-off-by: Mike Rapoport
> Acked-by: David Hildenbrand
Acked-by: Ard Biesheuvel
> ---
> arch/arm64/include/asm/memory.h | 2 +-
&
; Split out initialization of the reserved pages to a function with a
> meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> reserved regions and mark struct pages for the NOMAP regions as
> PageReserved.
>
> Signed-off-by: Mike Rapoport
> Reviewed-by: David H
human Khandual
> Signed-off-by: Mike Rapoport
> Reviewed-by: Anshuman Khandual
Acked-by: Ard Biesheuvel
> ---
> include/linux/mmzone.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 0d53eba1c3
On Wed, 14 Apr 2021 at 17:14, David Hildenbrand wrote:
>
> On 07.04.21 19:26, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This function is called for each
> > reserved regio
On Tue, 30 Mar 2021 at 15:56, Marc Zyngier wrote:
>
> On Tue, 30 Mar 2021 14:15:19 +0100,
> Ard Biesheuvel wrote:
> >
> > On Tue, 30 Mar 2021 at 15:04, Marc Zyngier wrote:
> > >
> > > On Tue, 30 Mar 2021 13:49:18 +0100,
> > > Ard Biesheuvel wro
On Tue, 30 Mar 2021 at 15:04, Marc Zyngier wrote:
>
> On Tue, 30 Mar 2021 13:49:18 +0100,
> Ard Biesheuvel wrote:
> >
> > On Tue, 30 Mar 2021 at 14:44, Marc Zyngier wrote:
> > >
> > > On Tue, 30 Mar 2021 12:21:26 +0100,
> > > Ard Biesheuvel
On Tue, 30 Mar 2021 at 14:44, Marc Zyngier wrote:
>
> On Tue, 30 Mar 2021 12:21:26 +0100,
> Ard Biesheuvel wrote:
> >
> > Commit f4693c2716b35d08 ("arm64: mm: extend linear region for 52-bit VA
> > configurations") introduced a new layout for the 52-bit V
("arm64: mm: extend linear region for 52-bit VA
configurations")
Signed-off-by: Ard Biesheuvel
---
Documentation/arm64/booting.rst | 6 +++---
arch/arm64/kvm/va_layout.c | 18 ++
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/Documentation/arm64/boo
On Wed, 6 Jan 2021 at 11:35, Andre Przywara wrote:
>
> From: Ard Biesheuvel
>
> Implement arch_get_random_seed_*() for ARM based on the firmware
> or hypervisor provided entropy source described in ARM DEN0098.
>
> This will make the kernel's random number generator con
On Fri, 5 Mar 2021 at 12:38, Marc Zyngier wrote:
>
> On Fri, 05 Mar 2021 02:38:17 +,
> Sami Tolvanen wrote:
> >
> > On Thu, Mar 4, 2021 at 2:34 PM Sami Tolvanen
> > wrote:
> > >
> > > On Thu, Mar 4, 2021 at 2:17 PM Marc Zyngier wrote:
> > > >
> > > > On Thu, 04 Mar 2021 21:25:41 +,
> >
On Mon, 8 Feb 2021 at 15:32, Will Deacon wrote:
>
> Hi Marc,
>
> On Mon, Feb 08, 2021 at 09:57:09AM +, Marc Zyngier wrote:
> > It recently came to light that there is a need to be able to override
> > some CPU features very early on, before the kernel is fully up and
> > running. The reasons f
On Mon, 25 Jan 2021 at 15:28, Marc Zyngier wrote:
>
> On 2021-01-25 14:19, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 14:54, Marc Zyngier wrote:
> >>
> >> On 2021-01-25 12:54, Ard Biesheuvel wrote:
>
> [...]
>
> >> > This struct
On Mon, 25 Jan 2021 at 14:54, Marc Zyngier wrote:
>
> On 2021-01-25 12:54, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 11:53, Marc Zyngier wrote:
> >>
> >> Given that the early cpufeature infrastructure has borrowed quite
> >> a lot of code from the
On Mon, 25 Jan 2021 at 11:53, Marc Zyngier wrote:
>
> Given that the early cpufeature infrastructure has borrowed quite
> a lot of code from the kaslr implementation, let's reimplement
> the matching of the "nokaslr" option with it.
>
> Signed-off-by: Marc Zyngier
> Acked-by: Catalin Marinas
> A
On Wed, 20 Jan 2021 at 14:01, Will Deacon wrote:
>
> On Wed, 6 Jan 2021 10:34:48 +, Andre Przywara wrote:
> > a fix to v5, now *really* fixing the wrong priority of SMCCC vs. RNDR
> > in arch_get_random_seed_long_early(). Apologies for messing this up
> > in v5 and thanks to broonie for being
On Fri, 15 Jan 2021 at 15:03, Marc Zyngier wrote:
>
> It looks like we have broken firmware out there that wrongly advertises
> a GICv2 compatibility interface, despite the CPUs not being able to deal
> with it.
>
> To work around this, check that the CPU initialising KVM is actually able
> to swi
On Fri, 8 Jan 2021 at 19:13, Marc Zyngier wrote:
>
> On 2021-01-08 17:59, Ard Biesheuvel wrote:
> > On Fri, 8 Jan 2021 at 18:12, Marc Zyngier wrote:
> >>
> >> It looks like we have broken firmware out there that wrongly
> >> advertises
> >> a GIC
On Fri, 8 Jan 2021 at 18:12, Marc Zyngier wrote:
>
> It looks like we have broken firmware out there that wrongly advertises
> a GICv2 compatibility interface, despite the CPUs not being able to deal
> with it.
>
> To work around this, check that the CPU initialising KVM is actually able
> to swit
r GCC version prior to 5.0,
> which *seems* to do the right thing. Hopefully we will be able to
> remove this at some point, but in the meantime this gets us going.
>
> Signed-off-by: Marc Zyngier
Acked-by: Ard Biesheuvel
> ---
> * From v1: Dropped the detection hack and rely on GCC_V
On Mon, 7 Dec 2020 at 18:41, Marc Zyngier wrote:
>
> On 2020-12-07 17:19, Ard Biesheuvel wrote:
> > (resend with David's email address fixed)
>
> Irk. Thanks for that.
>
> >> > +#ifdef CONFIG_CC_HAS_BROKEN_S_CONSTRAINT
> >> > +#defin
(resend with David's email address fixed)
On Mon, 7 Dec 2020 at 18:17, Ard Biesheuvel wrote:
>
> On Mon, 7 Dec 2020 at 16:43, Marc Zyngier wrote:
> >
> > GCC 4.9 seems to have a problem with the "S" asm constraint
> > when the symbol lives in the same
On Mon, 7 Dec 2020 at 16:43, Marc Zyngier wrote:
>
> GCC 4.9 seems to have a problem with the "S" asm constraint
> when the symbol lives in the same compilation unit, and pretends
> the constraint is impossible:
>
> $ cat x.c
> void *foo(void)
> {
> static int x;
> int *addr;
>
ver they wanted to take a pointer.
>
> Now that hyp relocations are fixed up, there is no need for the helper
> any logner. Remove it.
>
> Signed-off-by: David Brazdil
Acked-by: Ard Biesheuvel
> ---
> arch/arm64/include/asm/kvm_asm.h | 20
>
On Thu, 19 Nov 2020 at 17:26, David Brazdil wrote:
>
> Hyp code used to use absolute addressing via a constant pool to obtain
> the kernel VA of 3 symbols - panic, __hyp_panic_string and
> __kvm_handle_stub_hvc. This used to work because the kernel would
> relocate the addresses in the constant po
On Thu, 19 Nov 2020 at 17:25, David Brazdil wrote:
>
> Taking a function pointer will now generate a R_AARCH64_RELATIVE that is
> fixed up at early boot. Remove the alternative-based mechanism for
> converting the address from a kernel VA.
>
> Signed-off-by: David Brazd
On Thu, 19 Nov 2020 at 17:25, David Brazdil wrote:
>
> The arm64 kernel also supports packing of relocation data using the RELR
> format. Implement a parser of RELR data and fixup the relocations using
> the same infra as RELA relocs.
>
> Signed-off-by: David Brazdil
> ---
> arch/arm64/kvm/va_la
On Thu, 19 Nov 2020 at 17:25, David Brazdil wrote:
>
> KVM nVHE code runs under a different VA mapping than the kernel, hence
> so far it relied only on PC-relative addressing to avoid accidentally
> using a relocated kernel VA from a constant pool (see hyp_symbol_addr).
>
> So as to reduce the po
On Thu, 19 Nov 2020 at 17:25, David Brazdil wrote:
>
> We will need to recognize pointers in .rodata specific to hyp,
Why?
> so
> establish a .hyp.rodata ELF section. Merge it with the existing
> .hyp.data..ro_after_init as they are treated the same at runtime.
>
Does this mean HYP .text, .roda
On Fri, 20 Nov 2020 at 11:52, André Przywara wrote:
>
> On 19/11/2020 13:41, Ard Biesheuvel wrote:
>
> Hi,
>
> > On Fri, 13 Nov 2020 at 19:24, Andre Przywara wrote:
> >>
> >> The ARM architected TRNG firmware interface, described in ARM spec
> >>
On Fri, 13 Nov 2020 at 19:24, Andre Przywara wrote:
>
> The ARM architected TRNG firmware interface, described in ARM spec
> DEN0098, defines an ARM SMCCC based interface to a true random number
> generator, provided by firmware.
> This can be discovered via the SMCCC >=v1.1 interface, and provide
RANDOM initialisation from the SMCCC firmware driver
> - use a single bool in smccc.c to hold the initialisation state for arm64
> - handle endianess correctly in the KVM provider
>
> Andre Przywara (2):
> firmware: smccc: Introduce SMCCC TRNG framework
> arm64: Add support for
On Fri, 6 Nov 2020 at 16:30, Marc Zyngier wrote:
>
> On 2020-11-05 12:56, Andre Przywara wrote:
> > From: Ard Biesheuvel
> >
> > Implement arch_get_random_seed_*() for ARM based on the firmware
> > or hypervisor provided entropy source described in ARM DEN00
On Thu, 5 Nov 2020 at 15:13, Marc Zyngier wrote:
>
> On 2020-11-05 12:56, Andre Przywara wrote:
> > From: Ard Biesheuvel
> >
> > Provide a hypervisor implementation of the ARM architected TRNG
> > firmware
> > interface described in ARM spec DEN0098.
On Thu, 5 Nov 2020 at 15:30, Mark Rutland wrote:
>
> On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote:
> > On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote:
> > > On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
> > > > On Thu, Nov 05
On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote:
>
> On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
> > On Thu, Nov 05, 2020 at 12:56:55PM +, Andre Przywara wrote:
> >
> > > static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
> > > {
> > > + struct arm_sm
On Sat, 3 Oct 2020 at 12:30, Andrew Jones wrote:
>
> Hi Ard,
>
Hi Drew,
Thanks for taking a look.
> On Sat, Oct 03, 2020 at 10:56:04AM +0200, Ard Biesheuvel wrote:
> > Provide a hypervisor implementation of the ARM architected TRNG firmware
> > interface described
y
Cc: Suzuki K Poulose
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Lorenzo Pieralisi
Cc: Sudeep Holla
Cc: Sami Mujawar
Cc: Andre Przywara
Cc: Alexandru Elisei
Cc: Laszlo Ersek
Cc: Leif Lindholm
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm6
On Tue, 4 Aug 2020 at 14:45, Alex Bennée wrote:
>
> Hi,
>
> When building guest kernels for virtualisation we were bringing in a
> bunch of stuff from physical hardware which we don't need for our
> idealised fixable virtual PCI devices. This series makes some Kconfig
> changes to allow the Thunde
On Thu, 25 Jun 2020 at 10:16, Marc Zyngier wrote:
>
> On 2020-06-25 06:03, kernel test robot wrote:
> > Hi David,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v5.8-rc2 next-20200624]
> > [cannot app
On Fri, 24 Apr 2020 at 19:03, Will Deacon wrote:
>
> On Fri, Apr 24, 2020 at 09:40:51AM +0100, Will Deacon wrote:
> > On Thu, Apr 23, 2020 at 06:38:39PM +0100, Andre Przywara wrote:
> > > an update for the CFI flash emulation, addressing Alex' comments and
> > > adding direct mapping support.
> >
On Thu, 23 Apr 2020 at 19:55, Ard Biesheuvel wrote:
>
> On Thu, 23 Apr 2020 at 19:39, Andre Przywara wrote:
> >
> > Hi,
> >
> > an update for the CFI flash emulation, addressing Alex' comments and
> > adding direct mapping support.
> > The actual
On Thu, 23 Apr 2020 at 23:32, André Przywara wrote:
>
> On 23/04/2020 21:43, Ard Biesheuvel wrote:
>
> Hi Ard,
>
> > On Thu, 23 Apr 2020 at 19:55, Ard Biesheuvel wrote:
> >>
> >> On Thu, 23 Apr 2020 at 19:39, Andre Przywara
> >> wrote:
> &g
On Fri, 24 Apr 2020 at 14:08, André Przywara wrote:
>
> On 24/04/2020 07:45, Ard Biesheuvel wrote:
>
> Hi,
>
> (adding Leif for EDK-2 discussion)
>
> > On Thu, 23 Apr 2020 at 23:32, André Przywara wrote:
> >>
> >> On 23/04/2020 21:43, Ard Biesheuv
On Thu, 23 Apr 2020 at 19:39, Andre Przywara wrote:
>
> Hi,
>
> an update for the CFI flash emulation, addressing Alex' comments and
> adding direct mapping support.
> The actual code changes to the flash emulation are minimal, mostly this
> is about renaming and cleanups.
> This versions now adds
On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel wrote:
>
> On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei
> wrote:
> >
> > Hi,
> >
> > I've tested this patch by running badblocks and fio on a flash device
> > inside a
> > guest, everything w
On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei wrote:
>
> Hi,
>
> I've tested this patch by running badblocks and fio on a flash device inside a
> guest, everything worked as expected.
>
> I've also looked at the flowcharts for device operation from Intel Application
> Note 646, pages 12-21, and th
On Wed, 15 Apr 2020 at 18:11, André Przywara wrote:
>
> On 15/04/2020 16:55, Ard Biesheuvel wrote:
> > On Wed, 15 Apr 2020 at 17:43, Ard Biesheuvel wrote:
> >>
> >> On Tue, 7 Apr 2020 at 17:15, Alexandru Elisei
> >> wrote:
> >>>
> >>&
On Wed, 15 Apr 2020 at 18:36, André Przywara wrote:
>
> On 15/04/2020 17:20, Ard Biesheuvel wrote:
> > On Wed, 15 Apr 2020 at 18:11, André Przywara wrote:
> >>
> >> On 15/04/2020 16:55, Ard Biesheuvel wrote:
> >>> On Wed, 15 Apr 2020 at 17:43, Ard Bies
(+ Linus)
On Fri, 10 Apr 2020 at 12:45, Ard Biesheuvel wrote:
>
> On Fri, 17 Jan 2020 at 23:52, Florian Fainelli wrote:
> >
> > From: Andrey Ryabinin
> >
> > This patch enables the kernel address sanitizer for ARM. XIP_KERNEL has
> > not been tested and is
On Fri, 17 Jan 2020 at 23:52, Florian Fainelli wrote:
>
> From: Andrey Ryabinin
>
> This patch enables the kernel address sanitizer for ARM. XIP_KERNEL has
> not been tested and is therefore not allowed.
>
> Acked-by: Dmitry Vyukov
> Tested-by: Linus Walleij
> Signed-off-by: Abbott Liu
> Signe
Hi Mark,
On Tue, 18 Feb 2020 at 21:02, Mark Brown wrote:
>
> In an effort to clarify and simplify the annotation of assembly functions
> in the kernel new macros have been introduced. These replace ENTRY and
> ENDPROC and also add a new annotation for static functions which previously
> had no EN
On Fri, 21 Feb 2020 at 14:13, Will Deacon wrote:
>
> On Thu, Feb 20, 2020 at 04:58:39PM +, James Morse wrote:
> > KVM uses some of the static-inline helpers like icache_is_vipt() from
> > its HYP code. This assumes the function is inlined so that the code is
> > mapped to EL2. The compiler may
On Thu, 20 Feb 2020 at 18:33, James Morse wrote:
>
> Hi Ard,
>
> On 20/02/2020 17:04, Ard Biesheuvel wrote:
> > On Thu, 20 Feb 2020 at 17:58, James Morse wrote:
> >> It turns out KVM relies on the inline hint being honoured by the compiler
> >> in quite a few
On Thu, 20 Feb 2020 at 17:58, James Morse wrote:
>
> Hello!
>
> It turns out KVM relies on the inline hint being honoured by the compiler
> in quite a few more places than expected. Something about the Shadow Call
> Stack support[0] causes the compiler to avoid inline-ing and to place
> these func
On 11/8/19 12:19 PM, Christoffer Dall wrote:
> Hi,
>
> I had a look at our relatively complicated logic in
> kvm_arch_prepare_memory_region(), and was wondering if there was room to
> unify some of this handling between architectures.
>
> (If you haven't seen our implementation, you can find it in
space, so update that part as well.
Acked-by: Christoffer Dall
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/kvm_emulate.h | 3 +
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/kvm/sys_regs.c| 59 +++-
3 files changed, 61 insertions(+), 2 dele
system software (i.e.,
the kind that only receives odd fixes) doesn't take a performance hit
due to the trapping when iterating over the cachelines.
Acked-by: Christoffer Dall
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/kvm_emulate.h | 3 ++-
arch/arm64/kvm/sys_regs.c
nd, and it disabled otherwise
- add Christoffer's ack
Cc: suzuki.poul...@arm.com
Cc: marc.zyng...@arm.com
Cc: christoffer.d...@arm.com
Ard Biesheuvel (2):
arm64: kvm: expose sanitised cache type register to guest
arm64: kvm: describe data or unified caches as having 1 set and 1 way
arch/ar
On 19 October 2018 at 11:25, Andrew Jones wrote:
> On Thu, Oct 18, 2018 at 05:17:57PM +0800, Li Zhang wrote:
>> Hi,
>>
>> I run kvm-units-test on ARM server(QDF2400), but gicv2-ipi,
>> gicv2-active cases fail.
>> By debuging kvm-unit-tests source code, I found that interrupt is not
>> handled. do_
> On 9 Jun 2018, at 12:06, Christoffer Dall wrote:
>
>> On Fri, Jun 01, 2018 at 05:06:28PM +0200, Ard Biesheuvel wrote:
>> When booting a 64 KB pages kernel on a ACPI GICv3 system that
>> implements support for v2 emulation, the following warning is
>> produced
vgic_init: implement
kvm_vgic_hyp_init")
Signed-off-by: Ard Biesheuvel
---
virt/kvm/arm/vgic/vgic-v3.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index bdcf8e7a6161..72fc688c3e9d 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/vi
On 20 April 2018 at 17:38, Mark Rutland wrote:
> Hi Andrey,
>
> On Fri, Apr 20, 2018 at 04:59:35PM +0200, Andrey Konovalov wrote:
>> On Fri, Apr 20, 2018 at 10:13 AM, Marc Zyngier wrote:
>> >> The issue is that
>> >> clang doesn't know about the "S" asm constraint. I reported this to
>> >> clang
(+ Thomas)
On 16 March 2018 at 17:13, Mark Rutland wrote:
> On Fri, Mar 16, 2018 at 04:52:08PM +, Nick Desaulniers wrote:
>> + Sami (Google), Takahiro (Linaro)
>>
>> Just so I fully understand the problem enough to articulate it, we'd be
>> looking for the compiler to keep the jump tables for
On 16 March 2018 at 11:35, Andrew Jones wrote:
> On Fri, Mar 16, 2018 at 09:31:57AM +, Marc Zyngier wrote:
>> On 15/03/18 19:16, James Morse wrote:
>> >
>> > (I had a go at using 'Ush', to let the compiler schedule the adrp, but
>> > couldn't
>> > get it to work.)
>>
>> I tried that as well a
On 14 February 2018 at 17:38, Christoffer Dall
wrote:
> On Wed, Feb 14, 2018 at 02:43:42PM +, Dave Martin wrote:
>> [CC Ard, in case he has a view on how much we care about softirq NEON
>> performance regressions ... and whether my suggestions make sense]
>>
>> On Wed, Feb 14, 2018 at 11:15:54
On 1 February 2018 at 11:46, Marc Zyngier wrote:
> Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed,
> let's do that at boot time, and expose the version of the calling
> convention as part of the psci_ops structure.
>
> Acked-by: Lorenzo Pieralisi
> Signed-off-by: Marc Zyngier
ne primitive
> arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support
> arm64: Kill PSCI_GET_VERSION as a variant-2 workaround
>
I have given this a spin on my Overdrive, and everything seems to work
as expected, both in the host and in the guest (I single stepped
through the gue
CCC_ARCH_FEATURES is also defined as uint32_t,
but did end up being interpreted incorrectly by the SMCCCv1.1
implementation that is now upstream in ARM-TF
>
>> Cc: sta...@vger.kernel.org
>> Reported-by: Ard Biesheuvel
>> Acked-by: Ard Biesheuvel
>> Tested-by: Ard Biesheu
On 31 January 2018 at 14:35, Ard Biesheuvel wrote:
> On 31 January 2018 at 14:11, Marc Zyngier wrote:
>> On 31/01/18 13:56, Hanjun Guo wrote:
>>> Hi Marc,
>>>
>>> On 2018/1/30 1:45, Marc Zyngier wrote:
>>>> static int enable_psci_bp_hard
On 31 January 2018 at 14:11, Marc Zyngier wrote:
> On 31/01/18 13:56, Hanjun Guo wrote:
>> Hi Marc,
>>
>> On 2018/1/30 1:45, Marc Zyngier wrote:
>>> static int enable_psci_bp_hardening(void *data)
>>> {
>>> const struct arm64_cpu_capabilities *entry = data;
>>>
>>> -if (psci_ops.get_ver
On 30 January 2018 at 12:27, Marc Zyngier wrote:
> On 29/01/18 21:45, Ard Biesheuvel wrote:
>> On 29 January 2018 at 17:45, Marc Zyngier wrote:
>>> One of the major improvement of SMCCC v1.1 is that it only clobbers
>>> the first 4 registers, both on 32 and 64bit. Thi
On 29 January 2018 at 17:45, Marc Zyngier wrote:
> One of the major improvement of SMCCC v1.1 is that it only clobbers
> the first 4 registers, both on 32 and 64bit. This means that it
> becomes very easy to provide an inline version of the SMC call
> primitive, and avoid performing a function cal
On 29 January 2018 at 17:45, Marc Zyngier wrote:
> Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.
> It is lovely. Really.
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/include/asm/kvm_psci.h | 63
> arch/arm64/kernel/bpi.S
On 29 January 2018 at 10:07, Marc Zyngier wrote:
> On 29/01/18 09:42, Ard Biesheuvel wrote:
>> On 29 January 2018 at 09:36, Marc Zyngier wrote:
>>> On 28/01/18 23:08, Ard Biesheuvel wrote:
>>>> On 26 January 2018 at 14:28, Marc Zyngier wrote:
>>>&g
On 26 January 2018 at 14:28, Marc Zyngier wrote:
> In order to call into the firmware to apply workarounds, it is
> useful to find out whether we're using HVC or SMC. Let's expose
> this through the psci_ops.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/firmware/psci.c | 26 ++
On 26 January 2018 at 14:28, Marc Zyngier wrote:
> Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed,
> let's do that at boot time, and expose the version of the calling
> convention as part of the psci_ops structure.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/firmware/psci.
1 - 100 of 277 matches
Mail list logo
