Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp1381666rwo; Wed, 2 Aug 2023 13:08:39 -0700 (PDT) X-Google-Smtp-Source: APBJJlEPNnXCWa2WDuqoyOAd/bQ3w0xmJIxX2+Q0wYoeyYbP6/UeTXA878DBhVcSSiAL1mZQeNOn X-Received: by 2002:a17:906:64c1:b0:997:e8ab:fdf1 with SMTP id p1-20020a17090664c100b00997e8abfdf1mr6038945ejn.51.1691006919006; Wed, 02 Aug 2023 13:08:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691006918; cv=none; d=google.com; s=arc-20160816; b=Y5ecYEquazHaV63KN6A5DIPvfs/9asSdx55gCt9OF0TQxJZoJktED/WLMae0WiUAol FbkWSMu9vtaXzu5e78Ewb8GZycObdu6D1wKRw1hBWd63uMOulgrV9ssR2jSGMAiIXyV5 //jDRXRyBA/l9MOkIcZeVc774NQRlbZ+lgyUe7QdTeA5AcfbM7pU4YA6RKAYJl/gDCDt e978kXfSo7o61S7No1ZMrpIlD5aT/3e/atleHGqMEfwZqe0cjk6wjAbABcZwzdx2z5zc F0Ap63QEC3yxtLLas9O4ZOsbIKhTSYGZ6vBXC42zLFg5pYAufgHH+h8eBIBWFtGMxSf0 MPlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=aYBq5Q96CpGkfQxAbNmYKZm5+ExWaPEyMZGk2PekfWQ=; fh=zucpp8MTujBKF102SNBmrZrEcggo7osgWjpgKV7+jnE=; b=c6z1kpc1et3+ZfBagWkB6P9RKPUZ0vt2PKDxmBA6RCRE9NIlofNGY6Lw8viK3+qYgM JJlxbPfIvEr6AlJHOG9jqUerBfd880dArjlhEBfI9qNtjyPvJcPt5mhpp5oQVGcMUd0n lhFu/cgm090y+mgejO3tdcvq/jEhz6d2609S2YC1RgfSOrxlM9gmsVAcLtNRtaNBL6ZL y/lDwQantwp4Bl9szhcXVq9McjilAHt/FjnD/feon6P1DGkkVQ9dIDRVht2hMIySEAcX LgAONp40Ac9cm4TiE5X1ZGz2GMX3kmkYR8yV7LpxANJLtWZZpQ5BJ94dKrZT+HVIFvEw ng2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=kMvB8Nwz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sb10-20020a170906edca00b00993116b01f9si7616949ejb.120.2023.08.02.13.08.11; Wed, 02 Aug 2023 13:08:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=kMvB8Nwz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231136AbjHBSHr (ORCPT + 99 others); Wed, 2 Aug 2023 14:07:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229534AbjHBSHp (ORCPT ); Wed, 2 Aug 2023 14:07:45 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93E0F189 for ; Wed, 2 Aug 2023 11:07:41 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5843fed1e88so294807b3.0 for ; Wed, 02 Aug 2023 11:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690999661; x=1691604461; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=aYBq5Q96CpGkfQxAbNmYKZm5+ExWaPEyMZGk2PekfWQ=; b=kMvB8NwzZ2f28utg/bipBg/XV00In0z3HmKG57aADZb87Dfjxd94GUHXl9mRml5Bew pCQkyWj5/7EK2/cuY962nxJnZjnNrW4WnZb98E1jZCCTGJkWbBKrTLm0eYnLGehu1pbf p13/kRJ/W1XK5AqpAaod4tXiTgI9cWWV+bh2OCYyE/DhukaPEwQltpxce9GMftu7gL81 x2hn6z2yZpnKDo84U+sk7AGhtVFEHM0q+FppCyR1gbnN9i6LoLe43MjIbnBw4kCgMIru nfDY93evr9w1jWlS3VQ6gwSLHPgtE9uPRpfkANHF5fEF824fdvWP8t3ME9ZyPv43k7uy FMbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690999661; x=1691604461; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aYBq5Q96CpGkfQxAbNmYKZm5+ExWaPEyMZGk2PekfWQ=; b=j7IwC2eU7Q5WjkmPc3tP0inkiTlP50Y2lcsdgnEHCmyfNcYHJ3rVBMw+EpJqE3EMyx 3AKVjq6ZAj65dVpcJVH/2MiHvmtS7a3twImEXdmBBJegvYYHSFF6AYxi6v71rysfhpVe 3A/oQpm/E2QpoCPA0V9aud9oCjz+FGkil/d58vT9qCiVgcmwDNbgd2HnUJnG3SwYprxq xjleqTb+8Fa0jCHG8zmaT7zekFj1HvoZJt0izPxdP2RpgrfiV/G+x1a3XAUThcVTH+gV KkbmjP4c5Mde8locWLOFn4RFE5skM7wbhmwQ3N8FZ9X3rkaNTLFwjxBZfxPJAibvPPm4 5W1A== X-Gm-Message-State: ABy/qLY0JwkWr+gI/aiv2aYQGBPEZDirI8YxqeXXBqbKs+bssf69v0q8 uAfFKg0qhrnixvGHqATizM9nm+vjzwg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:441d:0:b0:586:4eae:b942 with SMTP id r29-20020a81441d000000b005864eaeb942mr88301ywa.4.1690999660863; Wed, 02 Aug 2023 11:07:40 -0700 (PDT) Date: Wed, 2 Aug 2023 11:07:39 -0700 In-Reply-To: <20230801020206.1957986-3-zhaotianrui@loongson.cn> Mime-Version: 1.0 References: <20230801020206.1957986-1-zhaotianrui@loongson.cn> <20230801020206.1957986-3-zhaotianrui@loongson.cn> Message-ID: Subject: Re: [PATCH v1 2/4] selftests: kvm: Add processor tests for LoongArch KVM From: Sean Christopherson To: Tianrui Zhao Cc: Shuah Khan , Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Vishal Annapurve , Huacai Chen , WANG Xuerui , loongarch@lists.linux.dev, Peter Xu , Vipin Sharma , maobibo@loongson.cn Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 01, 2023, Tianrui Zhao wrote: > Add processor tests for LoongArch KVM, including vcpu initialize Nit, AFAICT these aren't tests, this is simply the core KVM selftests support for LoongArch. > and tlb refill exception handler. > > Based-on: <20230720062813.4126751-1-zhaotianrui@loongson.cn> > Signed-off-by: Tianrui Zhao > --- > .../selftests/kvm/lib/loongarch/exception.S | 27 ++ > .../selftests/kvm/lib/loongarch/processor.c | 367 ++++++++++++++++++ > 2 files changed, 394 insertions(+) > create mode 100644 tools/testing/selftests/kvm/lib/loongarch/exception.S > create mode 100644 tools/testing/selftests/kvm/lib/loongarch/processor.c > > diff --git a/tools/testing/selftests/kvm/lib/loongarch/exception.S b/tools/testing/selftests/kvm/lib/loongarch/exception.S > new file mode 100644 > index 000000000000..19dc50993da4 > --- /dev/null > +++ b/tools/testing/selftests/kvm/lib/loongarch/exception.S > @@ -0,0 +1,27 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +#include "sysreg.h" > + > +/* address of refill exception should be 4K aligned */ > +.align 12 .align works on bytes, not on shifts. I.e. this will make handle_tlb_refill 12-byte aligned, not 4096-byte aligned. > +.global handle_tlb_refill > +handle_tlb_refill: > + csrwr t0, LOONGARCH_CSR_TLBRSAVE > + csrrd t0, LOONGARCH_CSR_PGD > + lddir t0, t0, 3 > + lddir t0, t0, 1 > + ldpte t0, 0 > + ldpte t0, 1 > + tlbfill > + csrrd t0, LOONGARCH_CSR_TLBRSAVE > + ertn > + > +/* address of general exception should be 4K aligned */ > +.align 12 Same thing here. > +.global handle_exception > +handle_exception: > +1: > + nop > + b 1b > + nop > + ertn > diff --git a/tools/testing/selftests/kvm/lib/loongarch/processor.c b/tools/testing/selftests/kvm/lib/loongarch/processor.c > new file mode 100644 > index 000000000000..2e50b6e2c556 > --- /dev/null > +++ b/tools/testing/selftests/kvm/lib/loongarch/processor.c > @@ -0,0 +1,367 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * KVM selftest LoongArch library code, including CPU-related functions. > + * Again, unnecessary IMO. If you do keep the comment, the extra line with a bare asterisk should be dropped. > + */ > + > +#include > +#include > +#include > + > +#include "kvm_util.h" > +#include "processor.h" > +#include "sysreg.h" > + > +#define DEFAULT_LOONGARCH_GUEST_STACK_VADDR_MIN 0xac0000 Why diverge from the common? #define DEFAULT_GUEST_STACK_VADDR_MIN 0xab6000 AFAIK, the common value is also mostly arbitrary, but that just makes it even more confusing as to why LoongArch needs to bump the min by 0x4000. > +uint64_t *virt_get_pte_hva(struct kvm_vm *vm, vm_vaddr_t gva) > +{ > + uint64_t *ptep; > + > + if (!vm->pgd_created) > + goto unmapped_gva; > + > + ptep = addr_gpa2hva(vm, vm->pgd) + pgd_index(vm, gva) * 8; > + if (!ptep) > + goto unmapped_gva; > + > + switch (vm->pgtable_levels) { > + case 4: > + ptep = addr_gpa2hva(vm, pte_addr(vm, *ptep)) + pud_index(vm, gva) * 8; > + if (!ptep) > + goto unmapped_gva; This wants a "fallthrough" annotation. > + case 3: > + ptep = addr_gpa2hva(vm, pte_addr(vm, *ptep)) + pmd_index(vm, gva) * 8; > + if (!ptep) > + goto unmapped_gva; > + case 2: > + ptep = addr_gpa2hva(vm, pte_addr(vm, *ptep)) + pte_index(vm, gva) * 8; > + if (!ptep) > + goto unmapped_gva; > + break; > + default: > + TEST_FAIL("Page table levels must be 2, 3, or 4"); Obviously it shouldn't come up, but print the actual pgtable_levels to make debug a wee bit easier e.g. TEST_FAIL("Got %u page table levels, expected 2, 3, or 4", vm->pgtable_levels); Mostly out of curiosity, but also because it looks like this was heavily copy+pasted from ARM: does LoongArch actually support 2-level page tables? > +static void loongarch_set_csr(struct kvm_vcpu *vcpu, uint64_t id, uint64_t val) > +{ > + uint64_t csrid; > + > + csrid = KVM_REG_LOONGARCH_CSR | KVM_REG_SIZE_U64 | 8 * id; > + vcpu_set_reg(vcpu, csrid, val); > +} > + > +static void loongarch_vcpu_setup(struct kvm_vcpu *vcpu) > +{ > + unsigned long val; > + int width; > + struct kvm_vm *vm = vcpu->vm; > + > + switch (vm->mode) { > + case VM_MODE_P48V48_16K: > + case VM_MODE_P40V48_16K: > + case VM_MODE_P36V48_16K: > + case VM_MODE_P36V47_16K: > + break; > + > + default: > + TEST_FAIL("Unknown guest mode, mode: 0x%x", vm->mode); > + } > + > + /* user mode and page enable mode */ > + val = PLV_USER | CSR_CRMD_PG; > + loongarch_set_csr(vcpu, LOONGARCH_CSR_CRMD, val); > + loongarch_set_csr(vcpu, LOONGARCH_CSR_PRMD, val); > + loongarch_set_csr(vcpu, LOONGARCH_CSR_EUEN, 1); > + loongarch_set_csr(vcpu, LOONGARCH_CSR_ECFG, 0); > + loongarch_set_csr(vcpu, LOONGARCH_CSR_TCFG, 0); > + loongarch_set_csr(vcpu, LOONGARCH_CSR_ASID, 1); > + > + width = vm->page_shift - 3; > + val = 0; > + switch (vm->pgtable_levels) { > + case 4: > + /* pud page shift and width */ > + val = (vm->page_shift + width * 2) << 20 | (width << 25); > + case 3: > + /* pmd page shift and width */ > + val |= (vm->page_shift + width) << 10 | (width << 15); > + case 2: > + /* pte page shift and width */ > + val |= vm->page_shift | width << 5; > + break; > + default: > + TEST_FAIL("Page table levels must be 2, 3, or 4"); > + } > + loongarch_set_csr(vcpu, LOONGARCH_CSR_PWCTL0, val); > + > + /* pgd page shift and width */ > + val = (vm->page_shift + width * (vm->pgtable_levels - 1)) | width << 6; > + loongarch_set_csr(vcpu, LOONGARCH_CSR_PWCTL1, val); > + > + loongarch_set_csr(vcpu, LOONGARCH_CSR_PGDL, vm->pgd); > + > + extern void handle_tlb_refill(void); > + extern void handle_exception(void); Eww. I get that it's probably undesirable to expose these via processor.h, but at least declare them outside of the function. > +struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, uint32_t vcpu_id, > + void *guest_code) > +{ > + return loongarch_vcpu_add(vm, vcpu_id, guest_code); Please drop the single-line passthrough, i.e. drop loongarch_vcpu_add(). I'm guessing you copy+pasted much of this from ARM. ARM's passthrough isn't a pure passthrough, which is directly related to why the "passthrough" is ok: there are other callers to aarch64_vcpu_add() that pass a non-NULL @source.