Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp1244081pxb; Thu, 14 Apr 2022 01:26:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6IsjPUOVkKcbuRmep3+8rOki0Z/3XOQG9CW4oQ3HBuyF+1CwcLVvncV0MzDT+b/pjOmt2 X-Received: by 2002:a05:6402:11d0:b0:420:e663:c57d with SMTP id j16-20020a05640211d000b00420e663c57dmr1770263edw.400.1649924780909; Thu, 14 Apr 2022 01:26:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649924780; cv=none; d=google.com; s=arc-20160816; b=Ti0zKWE2uM5VFC+u4ZOUVaw3NkHZAewwfxLwrqY2tYY6T6ewNI5FM8jzQWbBTKSnZ+ yYrR47ZFnoQMTq6cxbBIaHcDueNnROx1yTd06wtd1NngsgUqJRdDVeRvDbzjqolexURf 4wshI4AZqAuOhDcMo7UKNcYTXoz1NrVwyfTDQHmxQZMJMY5P9gAIKVBdDUYtt0V7ph4Q fgQW5ytDzcLWTGklcpo2O42f2+LQUJNCZTm4tkCn9uh9v14/3jnFxA+l5MtKJwDy58L5 UJG7EIQgobyVqOvKmQJBstGe2SWwWPv2O9BPscm5gjWVpTiU5mogxU2+mlU4OhqnxYMo aPBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=dvIfMnW3ta1GeJM0mPi4S5un5lCnCFe2bdKZdGIuHCU=; b=QiuRhL0NqDUlg7IeHH1OjUJKQBpvaVdyA/L8G06rmXvLJhjkv25X0zDUrPHkwK2H/I eH5IzXqKb8IwCcu8Z/JIvZT49k1WBc30hMUX5paPOmCcw+ixpeqIhvOU7Mpx39XGSKle 3L3fZtbgsKLFmU5Ps4bYeFUGrZLD9aVuAzam0mZPtQSE9bBlMl8Jehdy9zntdvWFD64j aurw84QCnDKw+ZDWSg8jqEkbP4q7QK9YDDu5V2K7L4Sdt/ZS/vLeFtn7KUmRFVM6Q2WV qQ29EAA3ttsT4LjDx+5Cpnr5VCqdnMBDC3Fwc8soXEL+vsrbJaIEK1FnuRVVFp4icLiL vv8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=R8dfgc56; 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 w10-20020a170906d20a00b006dfe7bc2fafsi1630683ejz.56.2022.04.14.01.25.54; Thu, 14 Apr 2022 01:26:20 -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=20210112 header.b=R8dfgc56; 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 S237385AbiDMRfC (ORCPT + 99 others); Wed, 13 Apr 2022 13:35:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237286AbiDMRe5 (ORCPT ); Wed, 13 Apr 2022 13:34:57 -0400 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 050F56C4B9 for ; Wed, 13 Apr 2022 10:32:34 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id f38so5074805ybi.3 for ; Wed, 13 Apr 2022 10:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dvIfMnW3ta1GeJM0mPi4S5un5lCnCFe2bdKZdGIuHCU=; b=R8dfgc56qLnlN3k5UWurhxvBrUPRSAE06TNJvMj0Il6YafAWaurttymnodJC9t7A0H ofdmFeaY+Kwy8XuHaM56OQVqovuR+KnV7A3dvg1U9R7oTH8jZukXelEeYurL22bCGIIa D/Ck3TTU+PaadHswQZtRdGuwKNRYw+moTk8UW1HeTFrDuG8QHqW4ZSN2RnVL3Lpg8lf8 pZ677glQ/2+SiR6k/pV0J1/2U1/EF4iO3go5x1ytAnC4zW4BrHEGAufsONJlieEiQs/J 15v1GALLbhyCNj0xXrvjrRCppGcwXcu1zieSwLwcJKBU2xgSNil5gZfFJN2pgH/mQK1r YphA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dvIfMnW3ta1GeJM0mPi4S5un5lCnCFe2bdKZdGIuHCU=; b=Qk5vLLqtECWV94ignbUAhHzI6mErnhtSsZLwbw6G3vYBYfeQWj0BdBLVdE3WAJrqZk 7JJcjDYQ4hByJXBUOOlAdyr67AZ55wT0dlI6niVl4EZ0h2mEru2YOci3W8rn2AwRV+qU xNuqpCiCBu6L2wKRmkoGvHrwbaYd6+ZwaD8+fgVO2EQIhFcA0kjgg/8fOBdC8xFMM55i QGQwWVu6MUZRPPR7aHMpTWEKrcpOn/8J5RYuRPOwXWXMK3oUqZhYrqrDZyJ41ruuybCa 3IVFuJGsGsxaCBaRwmtglZlLzjrxakcDlxk96gvAvMxhN+DJx/f/zp1tvGVDDlByjQAp JVzg== X-Gm-Message-State: AOAM530v0As3lxS311kqhvYnjkYrRGFiERSrrl7vp+SHJE1C2R1lwAYA ihEQE4gVK/8dLvPQNNRbyDdwJ5dvSGpDOqIJgs5dqg== X-Received: by 2002:a05:6902:1548:b0:641:a22c:2c6 with SMTP id r8-20020a056902154800b00641a22c02c6mr7774397ybu.357.1649871152929; Wed, 13 Apr 2022 10:32:32 -0700 (PDT) MIME-Version: 1.0 References: <20220407011605.1966778-1-rananta@google.com> <20220407011605.1966778-9-rananta@google.com> <7da91aa4-4fa9-13e6-5561-036cfce3e3e0@redhat.com> In-Reply-To: <7da91aa4-4fa9-13e6-5561-036cfce3e3e0@redhat.com> From: Raghavendra Rao Ananta Date: Wed, 13 Apr 2022 10:32:21 -0700 Message-ID: Subject: Re: [PATCH v5 08/10] selftests: KVM: aarch64: Introduce hypercall ABI test To: Gavin Shan , Oliver Upton Cc: Marc Zyngier , Andrew Jones , James Morse , Alexandru Elisei , Suzuki K Poulose , kvm@vger.kernel.org, Catalin Marinas , Peter Shier , linux-kernel@vger.kernel.org, Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham 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 Wed, Apr 13, 2022 at 2:07 AM Gavin Shan wrote: > > Hi Raghavendra, > > On 4/7/22 9:16 AM, Raghavendra Rao Ananta wrote: > > Introduce a KVM selftest to check the hypercall interface > > for arm64 platforms. The test validates the user-space's > > IOCTL interface to read/write the psuedo-firmware registers > > as well as its effects on the guest upon certain configurations. > > > > Signed-off-by: Raghavendra Rao Ananta > > --- > > tools/testing/selftests/kvm/.gitignore | 1 + > > tools/testing/selftests/kvm/Makefile | 1 + > > .../selftests/kvm/aarch64/hypercalls.c | 344 ++++++++++++++++++ > > 3 files changed, 346 insertions(+) > > create mode 100644 tools/testing/selftests/kvm/aarch64/hypercalls.c > > > > To be more precise, s/IOCTL/{GET,SET}_ONE_REG ? > Sure, I think that'll be better. > > diff --git a/tools/testing/selftests/kvm/.gitignore b/tools/testing/selftests/kvm/.gitignore > > index e82b816a6608..7ef52b3b1560 100644 > > --- a/tools/testing/selftests/kvm/.gitignore > > +++ b/tools/testing/selftests/kvm/.gitignore > > @@ -2,6 +2,7 @@ > > /aarch64/arch_timer > > /aarch64/debug-exceptions > > /aarch64/get-reg-list > > +/aarch64/hypercalls > > /aarch64/psci_test > > /aarch64/vgic_init > > /aarch64/vgic_irq > > diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile > > index 2f74f502de65..af4cb88bcf83 100644 > > --- a/tools/testing/selftests/kvm/Makefile > > +++ b/tools/testing/selftests/kvm/Makefile > > @@ -105,6 +105,7 @@ TEST_GEN_PROGS_x86_64 += system_counter_offset_test > > TEST_GEN_PROGS_aarch64 += aarch64/arch_timer > > TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions > > TEST_GEN_PROGS_aarch64 += aarch64/get-reg-list > > +TEST_GEN_PROGS_aarch64 += aarch64/hypercalls > > TEST_GEN_PROGS_aarch64 += aarch64/psci_test > > TEST_GEN_PROGS_aarch64 += aarch64/vgic_init > > TEST_GEN_PROGS_aarch64 += aarch64/vgic_irq > > diff --git a/tools/testing/selftests/kvm/aarch64/hypercalls.c b/tools/testing/selftests/kvm/aarch64/hypercalls.c > > new file mode 100644 > > index 000000000000..9941fb75772a > > --- /dev/null > > +++ b/tools/testing/selftests/kvm/aarch64/hypercalls.c > > @@ -0,0 +1,344 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > + > > +/* hypercalls: Check the ARM64's psuedo-firmware bitmap register interface. > > + * > > + * The test validates the basic hypercall functionalities that are exposed > > + * via the psuedo-firmware bitmap register. This includes the registers' > > + * read/write behavior before and after the VM has started, and if the > > + * hypercalls are properly masked or unmasked to the guest when disabled or > > + * enabled from the KVM userspace, respectively. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include "processor.h" > > + > > +#define FW_REG_ULIMIT_VAL(max_feat_bit) (GENMASK_ULL(max_feat_bit, 0)) > > + > > +/* Last valid bits of the bitmapped firmware registers */ > > +#define KVM_REG_ARM_STD_BMAP_BIT_MAX 0 > > +#define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 1 > > + > > +struct kvm_fw_reg_info { > > + uint64_t reg; /* Register definition */ > > + uint64_t max_feat_bit; /* Bit that represents the upper limit of the feature-map */ > > +}; > > + > > +#define FW_REG_INFO(r, bit_max) \ > > + { \ > > + .reg = r, \ > > + .max_feat_bit = bit_max, \ > > + } > > + > > +static const struct kvm_fw_reg_info fw_reg_info[] = { > > + FW_REG_INFO(KVM_REG_ARM_STD_BMAP, KVM_REG_ARM_STD_BMAP_BIT_MAX), > > + FW_REG_INFO(KVM_REG_ARM_STD_HYP_BMAP, KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX), > > + FW_REG_INFO(KVM_REG_ARM_VENDOR_HYP_BMAP, KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX), > > +}; > > + > > This can be simplifed by: > > #define FW_REG_INFO(r) \ > { .reg = r, \ > .max_feat_bit = r_##BIT_MAX, \ > } > > static const struct kvm_fw_reg_info fw_reg_info[] = { > FW_REG_INFO(KVM_REG_ARM_STD_BMAP), > FW_REG_INFO(KVM_REG_ARM_STD_HYP_BMAP), > FW_REG_INFO(KVM_REG_ARM_VENDOR_HYP_BMAP), > }; > Yes, probably that looks better. Thanks for the suggestion. > > +enum test_stage { > > + TEST_STAGE_REG_IFACE, > > + TEST_STAGE_HVC_IFACE_FEAT_DISABLED, > > + TEST_STAGE_HVC_IFACE_FEAT_ENABLED, > > + TEST_STAGE_HVC_IFACE_FALSE_INFO, > > + TEST_STAGE_END, > > +}; > > + > > +static int stage; > > + > > I think it'd better to initialize @stage to TEST_STAGE_REG_IFACE. > Will do. > > +struct test_hvc_info { > > + uint32_t func_id; > > + int64_t arg0; > > +}; > > + > > +#define TEST_HVC_INFO(f, a0) \ > > + { \ > > + .func_id = f, \ > > + .arg0 = a0, \ > > + } > > + > > According to those functions (smccc_get_{function, argx}()) defined > in include/kvm/arm_hypercalls.h, @arg0 would have type of "uint64_t" > if I'm correct. Besides, @func_id is arg0 and arg0 should be arg1? > So if I'm correct, this would be: > > struct test_hvc_info { > uint32_t func_id; > uint64_t arg1 > }; > Thanks for noticing this! I'll change it to 'unit64'. Regarding the argument naming, I understand that it's a little confusing. I went with 'arg0' to align with the selftest library's convention. But, I agree that it's not aligned with what the kernel is used to. Oliver, do you think we can start the argument naming from a1/arg1 in [1]? > > +static const struct test_hvc_info hvc_info[] = { > > + /* KVM_REG_ARM_STD_BMAP */ > > + TEST_HVC_INFO(ARM_SMCCC_TRNG_VERSION, 0), > > + TEST_HVC_INFO(ARM_SMCCC_TRNG_FEATURES, ARM_SMCCC_TRNG_RND64), > > + TEST_HVC_INFO(ARM_SMCCC_TRNG_GET_UUID, 0), > > + TEST_HVC_INFO(ARM_SMCCC_TRNG_RND32, 0), > > + TEST_HVC_INFO(ARM_SMCCC_TRNG_RND64, 0), > > + > > + /* KVM_REG_ARM_STD_HYP_BMAP */ > > + TEST_HVC_INFO(ARM_SMCCC_ARCH_FEATURES_FUNC_ID, ARM_SMCCC_HV_PV_TIME_FEATURES), > > + TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_FEATURES, ARM_SMCCC_HV_PV_TIME_ST), > > + TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_ST, 0), > > + > > + /* KVM_REG_ARM_VENDOR_HYP_BMAP */ > > + TEST_HVC_INFO(ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID, > > + ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID), > > + TEST_HVC_INFO(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID, KVM_PTP_VIRT_COUNTER), > > +}; > > + > > +/* Feed false hypercall info to test the KVM behavior */ > > +static const struct test_hvc_info false_hvc_info[] = { > > + /* Feature support check against a different family of hypercalls */ > > + TEST_HVC_INFO(ARM_SMCCC_TRNG_FEATURES, ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID), > > + TEST_HVC_INFO(ARM_SMCCC_ARCH_FEATURES_FUNC_ID, ARM_SMCCC_TRNG_RND64), > > + TEST_HVC_INFO(ARM_SMCCC_HV_PV_TIME_FEATURES, ARM_SMCCC_TRNG_RND64), > > +}; > > + > > +static void guest_test_hvc(const struct test_hvc_info *hc_info) > > +{ > > + unsigned int i; > > + struct arm_smccc_res res; > > + unsigned int hvc_info_arr_sz; > > + > > + hvc_info_arr_sz = > > + hc_info == hvc_info ? ARRAY_SIZE(hvc_info) : ARRAY_SIZE(false_hvc_info); > > + > > + for (i = 0; i < hvc_info_arr_sz; i++, hc_info++) { > > + > > + memset(&res, 0, sizeof(res)); > > + smccc_hvc(hc_info->func_id, hc_info->arg0, 0, 0, 0, 0, 0, 0, &res); > > + > > Unnecessary empty line before memset(). I don't find where smccc_hvc() > is defined. > I can clear the line and for the definition of smccc_hvc(), I applied Oliver's patch [1]. > > + switch (stage) { > > + case TEST_STAGE_HVC_IFACE_FEAT_DISABLED: > > + case TEST_STAGE_HVC_IFACE_FALSE_INFO: > > + GUEST_ASSERT_3(res.a0 == SMCCC_RET_NOT_SUPPORTED, > > + res.a0, hc_info->func_id, hc_info->arg0); > ^^ > > It seems the code here isn't properly aligned. Maybe it's your > preference :) > I think my editor is acting weird. I'll check again. Thanks for catching this! > > + break; > > + case TEST_STAGE_HVC_IFACE_FEAT_ENABLED: > > + GUEST_ASSERT_3(res.a0 != SMCCC_RET_NOT_SUPPORTED, > > + res.a0, hc_info->func_id, hc_info->arg0); > > + break; > > + default: > > + GUEST_ASSERT_1(0, stage); > > + } > > + } > > +} > > + > > +static void guest_code(void) > > +{ > > + while (stage != TEST_STAGE_END) { > > + switch (stage) { > > + case TEST_STAGE_REG_IFACE: > > + break; > > + case TEST_STAGE_HVC_IFACE_FEAT_DISABLED: > > + case TEST_STAGE_HVC_IFACE_FEAT_ENABLED: > > + guest_test_hvc(hvc_info); > > + break; > > + case TEST_STAGE_HVC_IFACE_FALSE_INFO: > > + guest_test_hvc(false_hvc_info); > > + break; > > + default: > > + GUEST_ASSERT_1(0, stage); > > + } > > + > > + GUEST_SYNC(stage); > > + } > > + > > + GUEST_DONE(); > > +} > > + > > +static int set_fw_reg(struct kvm_vm *vm, uint64_t id, uint64_t val) > > +{ > > + struct kvm_one_reg reg = { > > + .id = id, > > + .addr = (uint64_t)&val, > > + }; > > + > > + return _vcpu_ioctl(vm, 0, KVM_SET_ONE_REG, ®); > > +} > > + > > +static void get_fw_reg(struct kvm_vm *vm, uint64_t id, uint64_t *addr) > > +{ > > + struct kvm_one_reg reg = { > > + .id = id, > > + .addr = (uint64_t)addr, > > + }; > > + > > + vcpu_ioctl(vm, 0, KVM_GET_ONE_REG, ®); > > +} > > + > > +struct st_time { > > + uint32_t rev; > > + uint32_t attr; > > + uint64_t st_time; > > +}; > > + > > +#define STEAL_TIME_SIZE ((sizeof(struct st_time) + 63) & ~63) > > +#define ST_GPA_BASE (1 << 30) > > + > > +static void steal_time_init(struct kvm_vm *vm) > > +{ > > + uint64_t st_ipa = (ulong)ST_GPA_BASE; > > + unsigned int gpages; > > + struct kvm_device_attr dev = { > > + .group = KVM_ARM_VCPU_PVTIME_CTRL, > > + .attr = KVM_ARM_VCPU_PVTIME_IPA, > > + .addr = (uint64_t)&st_ipa, > > + }; > > + > > + gpages = vm_calc_num_guest_pages(VM_MODE_DEFAULT, STEAL_TIME_SIZE); > > + vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, ST_GPA_BASE, 1, gpages, 0); > > + > > + vcpu_ioctl(vm, 0, KVM_SET_DEVICE_ATTR, &dev); > > +} > > + > > It might be helpful to do TEST_FAIL() on error returned from > this vcpu_ioctl(), or skip those PVTIME SMCCC calls accordingly > if the attribute isn't set successfully. > vcpu_ioctl() does a TEST_ASSERT() for us. Of course we can check it ourselves and skip if needed, but don't you think that may go unnoticed should any future changes tries to mess with steal_time_init() incorrectly and we'd end up skipping the test forever until we really notice skipped test? > > +static void test_fw_regs_before_vm_start(struct kvm_vm *vm) > > +{ > > + uint64_t val; > > + unsigned int i; > > + int ret; > > + > > + for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++) { > > + const struct kvm_fw_reg_info *reg_info = &fw_reg_info[i]; > > + > > + /* First 'read' should be an upper limit of the features supported */ > > + get_fw_reg(vm, reg_info->reg, &val); > > + TEST_ASSERT(val == FW_REG_ULIMIT_VAL(reg_info->max_feat_bit), > > + "Expected all the features to be set for reg: 0x%lx; expected: 0x%llx; read: 0x%lx\n", > > + reg_info->reg, GENMASK_ULL(reg_info->max_feat_bit, 0), val); > > + > > s/GENMASK_ULL(...)/FW_REG_ULIMIT_VAL(...) > Right, that's better. > > + /* Test a 'write' by disabling all the features of the register map */ > > + ret = set_fw_reg(vm, reg_info->reg, 0); > > + TEST_ASSERT(ret == 0, > > + "Failed to clear all the features of reg: 0x%lx; ret: %d\n", > > + reg_info->reg, errno); > > + > > + get_fw_reg(vm, reg_info->reg, &val); > > + TEST_ASSERT(val == 0, > > + "Expected all the features to be cleared for reg: 0x%lx\n", reg_info->reg); > > + > > + /* > > + * Test enabling a feature that's not supported. > > + * Avoid this check if all the bits are occupied. > > + */ > > + if (reg_info->max_feat_bit < 63) { > > + ret = set_fw_reg(vm, reg_info->reg, BIT(reg_info->max_feat_bit + 1)); > > + TEST_ASSERT(ret != 0 && errno == EINVAL, > > + "Unexpected behavior or return value (%d) while setting an unsupported feature for reg: 0x%lx\n", > > + errno, reg_info->reg); > > + } > > + } > > +} > > + > > +static void test_fw_regs_after_vm_start(struct kvm_vm *vm) > > +{ > > + uint64_t val; > > + unsigned int i; > > + int ret; > > + > > + for (i = 0; i < ARRAY_SIZE(fw_reg_info); i++) { > > + const struct kvm_fw_reg_info *reg_info = &fw_reg_info[i]; > > + > > + /* > > + * Before starting the VM, the test clears all the bits. > > + * Check if that's still the case. > > + */ > > + get_fw_reg(vm, reg_info->reg, &val); > > + TEST_ASSERT(val == 0, > > + "Expected all the features to be cleared for reg: 0x%lx\n", > > + reg_info->reg); > > + > > + /* > > + * Test setting the last read value. KVM should allow this > > + * even if VM has started running. > > + */ > > + ret = set_fw_reg(vm, reg_info->reg, val); > > + TEST_ASSERT(ret == 0, > > + "Failed to set the register with previously read value after Vm start for reg: 0x%lx; ret: %d\n", > > + reg_info->reg, errno); > > + > > + /* > > + * Set all the features for this register again. KVM shouldn't > > + * allow this as the VM is running. > > + */ > > + ret = set_fw_reg(vm, reg_info->reg, FW_REG_ULIMIT_VAL(reg_info->max_feat_bit)); > > + TEST_ASSERT(ret != 0 && errno == EBUSY, > > + "Unexpected behavior or return value (%d) while setting a feature while VM is running for reg: 0x%lx\n", > > + errno, reg_info->reg); > > + } > > +} > > + > > +static struct kvm_vm *test_vm_create(void) > > +{ > > + struct kvm_vm *vm; > > + > > + vm = vm_create_default(0, 0, guest_code); > > + > > + ucall_init(vm, NULL); > > + steal_time_init(vm); > > + > > + return vm; > > +} > > + > > +static struct kvm_vm *test_guest_stage(struct kvm_vm *vm) > > +{ > > + struct kvm_vm *ret_vm = vm; > > + > > + pr_debug("Stage: %d\n", stage); > > + > > + switch (stage) { > > + case TEST_STAGE_REG_IFACE: > > + test_fw_regs_after_vm_start(vm); > > + break; > > + case TEST_STAGE_HVC_IFACE_FEAT_DISABLED: > > + /* Start a new VM so that all the features are now enabled by default */ > > + kvm_vm_free(vm); > > + ret_vm = test_vm_create(); > > + break; > > + case TEST_STAGE_HVC_IFACE_FEAT_ENABLED: > > + case TEST_STAGE_HVC_IFACE_FALSE_INFO: > > + break; > > + default: > > + TEST_FAIL("Unknown test stage: %d\n", stage); > > + } > > + > > + stage++; > > + sync_global_to_guest(vm, stage); > > + > > + return ret_vm; > > +} > > + > > +static void test_run(void) > > +{ > > + struct kvm_vm *vm; > > + struct ucall uc; > > + bool guest_done = false; > > + > > + vm = test_vm_create(); > > + > > + test_fw_regs_before_vm_start(vm); > > + > > + while (!guest_done) { > > + vcpu_run(vm, 0); > > + > > + switch (get_ucall(vm, 0, &uc)) { > > + case UCALL_SYNC: > > + vm = test_guest_stage(vm); > > + break; > > + case UCALL_DONE: > > + guest_done = true; > > + break; > > + case UCALL_ABORT: > > + TEST_FAIL("%s at %s:%ld\n\tvalues: 0x%lx, 0x%lx; 0x%lx, stage: %u", > > + (const char *)uc.args[0], __FILE__, uc.args[1], > > + uc.args[2], uc.args[3], uc.args[4], stage); > > + break; > > + default: > > + TEST_FAIL("Unexpected guest exit\n"); > > + } > > + } > > + > > + kvm_vm_free(vm); > > +} > > + > > +int main(void) > > +{ > > + setbuf(stdout, NULL); > > + > > + test_run(); > > + return 0; > > +} > > > > Thanks, > Gavin > Thanks for taking the time to review. Regards, Raghavendra [1]: https://lore.kernel.org/kvmarm/20220409184549.1681189-11-oupton@google.com/T/#u