Re: [PATCH 1/3] KVM: arm64: Fix S1PTW handling on RO memslots

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 gues

Re: [PATCH 1/3] KVM: arm64: Fix S1PTW handling on RO memslots

nd-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: Marc Zyngier &

[PATCH] arm64: kvm: avoid unnecessary absolute addressing via literals

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

Re: [kbuild-all] Re: [PATCH v2 6/9] KVM: arm64: Detect and handle hypervisor stack overflows

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

Re: [kbuild-all] Re: [PATCH v2 6/9] KVM: arm64: Detect and handle hypervisor stack overflows

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!

Re: [PATCH][kvmtool] virtio/pci: Signal INTx interrupts as level instead of edge

rspace (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 > --- > pci.c

[RFC PATCH 12/12] arm64: hugetlb: use set_pte_at() not set_pte() to provide mm pointer

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

[RFC PATCH 11/12] arm64: efi: use set_pte_at() not set_pte() in order to pass mm pointer

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

[RFC PATCH 10/12] mm: add default definition of p4d_index()

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

[RFC PATCH 09/12] arm64: mm: remap kernel page tables read-only at end of init

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

[RFC PATCH 08/12] arm64: mm: remap kernel PTE level page tables r/o in the linear region

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

[RFC PATCH 07/12] arm64: mm: remap PTE level user page tables r/o in the linear region

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

[RFC PATCH 06/12] arm64: mm: remap PMD pages r/o in linear region

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

[RFC PATCH 05/12] arm64: mm: remap PUD pages r/o in linear region

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

[RFC PATCH 04/12] arm64: mm: remap PGD pages r/o in the linear region after allocation

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

[RFC PATCH 03/12] arm64: mm: use a fixmap slot for user page table modifications

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

[RFC PATCH 02/12] arm64: mm: add helpers to remap page tables read-only/read-write

-by: 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

[RFC PATCH 00/12] arm64: implement read-only page tables

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 page

[RFC PATCH 01/12] asm-generic/pgalloc: allow arch to override PMD alloc/free routines

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

Re: [PATCH] KVM: arm64: vgic-v3: Restrict SEIS workaround to known broken systems

; 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-by

Re: [PATCH] Documentation, dt, numa: Add note to empty NUMA node

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

Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()

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, > > &g

Re: [PATCH v4 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()

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

Re: [PATCH v4 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()

fn_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/arm64

Re: [PATCH v4 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid()

; > 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 +- &

Re: [PATCH v4 2/4] memblock: update initialization of reserved pages

; 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

Re: [PATCH v4 1/4] include/linux/mmzone.h: add documentation for pfn_valid()

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

Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages

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

Re: [PATCH] arm64: kvm: handle 52-bit VA regions correctly under nVHE

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

Re: [PATCH] arm64: kvm: handle 52-bit VA regions correctly under nVHE

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

Re: [PATCH] arm64: kvm: handle 52-bit VA regions correctly under nVHE

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-b

[PATCH] arm64: kvm: handle 52-bit VA regions correctly under nVHE

m64: 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/booting.rst b

Re: [PATCH v6 3/5] ARM: implement support for SMCCC TRNG entropy source

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 consu

Re: [PATCH] KVM: arm64: Disable LTO in hyp

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 +, >

Re: [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth

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

Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

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

Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

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

Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

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 >

Re: [PATCH v6 0/5] ARM: arm64: Add SMCCC TRNG entropy service

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

Re: [PATCH v2 2/2] KVM: arm64: Workaround firmware wrongly advertising GICv2-on-v3 compatibility

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

Re: [PATCH 2/2] KVM: arm64: Workaround firmware wrongly advertising GICv2-on-v3 compatibility

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

Re: [PATCH 2/2] KVM: arm64: Workaround firmware wrongly advertising GICv2-on-v3 compatibility

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

Re: [PATCH] arm64: Work around broken GCC 4.9 handling of "S" constraint

rsion 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_VERSION >

Re: [PATCH] arm64: Work around broken GCC handling of "S" constraint

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 > >> > +#define SYM

Re: [PATCH] arm64: Work around broken GCC handling of "S" constraint

(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 s

Re: [PATCH] arm64: Work around broken GCC handling of "S" constraint

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; >

Re: [RFC PATCH 6/6] kvm: arm64: Remove hyp_symbol_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 >

Re: [RFC PATCH 5/6] kvm: arm64: Fix constant-pool users in hyp

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

Re: [RFC PATCH 4/6] kvm: arm64: Remove patching of fn pointers in hyp

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

Re: [RFC PATCH 3/6] kvm: arm64: Fix up RELR relocation in hyp code/data

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 > --- >

Re: [RFC PATCH 2/6] kvm: arm64: Fix up RELA relocations in hyp code/data

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

Re: [RFC PATCH 1/6] kvm: arm64: Set up .hyp.rodata ELF section

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,

Re: [PATCH v3 4/5] arm64: Add support for SMCCC TRNG entropy source

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 > >&g

Re: [PATCH v3 4/5] arm64: Add support for SMCCC TRNG entropy source

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

Re: [PATCH v3 0/5] ARM: arm64: Add SMCCC TRNG entropy service

M 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 SMCC

Re: [PATCH v2 3/5] ARM: implement support for SMCCC TRNG entropy source

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 D

Re: [PATCH v2 5/5] KVM: arm64: implement the TRNG hypervisor call

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.

Re: [PATCH v2 4/5] arm64: Add support for SMCCC TRNG entropy source

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

Re: [PATCH v2 4/5] arm64: Add support for SMCCC TRNG entropy source

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

Re: [PATCH] KVM: arm64: implement the TRNG hypervisor call

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

[PATCH] KVM: arm64: implement the TRNG hypervisor call

: 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/arm64/kvm

Re: [RFC PATCH v1 0/3] put arm64 kvm_config on a diet

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

Re: [PATCH v3 08/15] arm64: kvm: Split hyp/switch.c to VHE/nVHE

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

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

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. > >

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

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 code

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

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

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

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

Re: [PATCH kvmtool v4 0/5] Add CFI flash emulation

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

Re: [PATCH kvmtool v3] Add emulation for CFI compatible flash memory

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

Re: [PATCH kvmtool v3] Add emulation for CFI compatible flash memory

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

Re: [PATCH kvmtool v3] Add emulation for CFI compatible flash memory

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: > >>> > >>&

Re: [PATCH kvmtool v3] Add emulation for CFI compatible flash memory

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

Re: [PATCH v7 7/7] ARM: Enable KASan for ARM

(+ 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

Re: [PATCH v7 7/7] ARM: Enable KASan for ARM

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 >

Re: [PATCH 12/18] arm64: kernel: Convert to modern annotations for assembly functions

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

Re: [PATCH 3/3] arm64: Ask the compiler to __always_inline functions used by KVM at HYP

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

Re: [PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP

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

Re: [PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP

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

Re: Memory regions and VMAs across architectures

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

[PATCH v2 1/2] arm64: kvm: expose sanitised cache type register to guest

, 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 deletions

[PATCH v2 2/2] arm64: kvm: describe data or unified caches as having 1 set and 1 way

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| 15

[PATCH v2 0/2] arm64: kvm: cache ID register trapping

, 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/arm64/include/asm

Re: kvm-unit-tests gicv2 cases fail

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.

Re: [PATCH] KVM: arm/arm64: drop resource size check for GICV window

> 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 >> pro

[PATCH] KVM: arm/arm64: drop resource size check for GICV window

_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/virt/kv

Re: Clang arm64 build is broken

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"

Re: arm64 kvm built with clang doesn't boot

(+ 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

Re: [PATCH v6 06/26] KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state

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

Re: [PATCH v3 09/41] KVM: arm64: Defer restoring host VFP state to vcpu_put

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

Re: [PATCH v3 14/18] firmware/psci: Expose SMCCC version through psci_ops

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

Re: [PATCH v3 00/18] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation

smccc: Implement SMCCC v1.1 inline 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

Re: [PATCH v3 15/18] arm/arm64: smccc: Make function identifiers an unsigned quantity

issue, but the argument, which, for SMCCC_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 <ard.biesheu...@linar

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 31 January 2018 at 14:35, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 31 January 2018 at 14:11, Marc Zyngier <marc.zyng...@arm.com> wrote: >> On 31/01/18 13:56, Hanjun Guo wrote: >>> Hi Marc, >>> >>> On 2018/1/30 1:45, Marc Zyngier

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

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; >>> >>> -

Re: [PATCH v2 15/16] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive

On 30 January 2018 at 12:27, Marc Zyngier <marc.zyng...@arm.com> wrote: > On 29/01/18 21:45, Ard Biesheuvel wrote: >> On 29 January 2018 at 17:45, Marc Zyngier <marc.zyng...@arm.com> wrote: >>> One of the major improvement of SMCCC v1.1 is that it only clobbers &

Re: [PATCH v2 15/16] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive

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

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

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

Re: [PATCH 14/14] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 29 January 2018 at 10:07, Marc Zyngier <marc.zyng...@arm.com> wrote: > On 29/01/18 09:42, Ard Biesheuvel wrote: >> On 29 January 2018 at 09:36, Marc Zyngier <marc.zyng...@arm.com> wrote: >>> On 28/01/18 23:08, Ard Biesheuvel wrote: >>>> On 26 Janu

Re: [PATCH 12/14] firmware/psci: Expose PSCI conduit

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 > --- >

Re: [PATCH 13/14] firmware/psci: Expose SMCCC version through psci_ops

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

  1   2   3   >