lkml.org 
[lkml]   [2021]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [RFC PATCH v2 11/26] KVM: arm64: Stub CONFIG_DEBUG_LIST at Hyp
    On Fri, Jan 08, 2021 at 12:15:09PM +0000, Quentin Perret wrote:
    > In order to use the kernel list library at EL2, introduce stubs for the
    > CONFIG_DEBUG_LIST out-of-lines calls.
    >
    > Signed-off-by: Quentin Perret <qperret@google.com>
    > ---
    > arch/arm64/kvm/hyp/nvhe/Makefile | 2 +-
    > arch/arm64/kvm/hyp/nvhe/stub.c | 22 ++++++++++++++++++++++
    > 2 files changed, 23 insertions(+), 1 deletion(-)
    > create mode 100644 arch/arm64/kvm/hyp/nvhe/stub.c
    >
    > diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
    > index 1fc0684a7678..33bd381d8f73 100644
    > --- a/arch/arm64/kvm/hyp/nvhe/Makefile
    > +++ b/arch/arm64/kvm/hyp/nvhe/Makefile
    > @@ -10,7 +10,7 @@ lib-objs := clear_page.o copy_page.o memcpy.o memset.o
    > lib-objs := $(addprefix ../../../lib/, $(lib-objs))
    >
    > obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o \
    > - hyp-main.o hyp-smp.o psci-relay.o early_alloc.o
    > + hyp-main.o hyp-smp.o psci-relay.o early_alloc.o stub.o
    > obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
    > ../fpsimd.o ../hyp-entry.o ../exception.o
    > obj-y += $(lib-objs)
    > diff --git a/arch/arm64/kvm/hyp/nvhe/stub.c b/arch/arm64/kvm/hyp/nvhe/stub.c
    > new file mode 100644
    > index 000000000000..c0aa6bbfd79d
    > --- /dev/null
    > +++ b/arch/arm64/kvm/hyp/nvhe/stub.c
    > @@ -0,0 +1,22 @@
    > +// SPDX-License-Identifier: GPL-2.0-only
    > +/*
    > + * Stubs for out-of-line function calls caused by re-using kernel
    > + * infrastructure at EL2.
    > + *
    > + * Copyright (C) 2020 - Google LLC
    > + */
    > +
    > +#include <linux/list.h>
    > +
    > +#ifdef CONFIG_DEBUG_LIST
    > +bool __list_add_valid(struct list_head *new, struct list_head *prev,
    > + struct list_head *next)
    > +{
    > + return true;
    > +}
    > +
    > +bool __list_del_entry_valid(struct list_head *entry)
    > +{
    > + return true;
    > +}
    > +#endif
    Can we get away with defining our own CHECK_DATA_CORRUPTION macro instead?

    Will

    \
     
     \ /
      Last update: 2021-02-01 20:08    [W:4.122 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site