Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2773191pxb; Tue, 21 Sep 2021 07:22:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVCYosJguQ+Ip2hrw4kNxDlZ3A7/9tqNHrq1XasvRzF2rkbP1QGpQPZjekkIT+Fpgz+J8b X-Received: by 2002:a17:906:318b:: with SMTP id 11mr36583316ejy.493.1632234133106; Tue, 21 Sep 2021 07:22:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632234133; cv=none; d=google.com; s=arc-20160816; b=CfiAphEc+NUWYSCgnO1cETW9m6oWLBxNos2T/gDa+54dHCWW0kpqAcnpI3pW15SMLj MbKSTj9eesSK8YQQ0vMTb1Ey78t9wO/tbHzaBwNmn5ArzeZHy/IgAfLOfAI0xY5SQYCf 01QP9ZEfUk/zxQya4TT0NYpwcGwKvRR+eQRgKa58jnofXBxK5Fph0xoHnDB+ShG0S693 a/uvW325na/PxLezA8frqG7ngKY5YzOWv9A338tvt/A9AyWpJmGd3k4P0mjmnwyLMYyU GwKbNg7WMrJa7TcWMX3QRGdliBQPbxFFEjUttsEv0/+u9g13Cj35Jt6vONNdFE8E/4Wd SsFw== 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=KI5XuvdO6ZDnwox9e0Y7Y2l7MqmHpltl1BSps4mHQrg=; b=FMDQc/Stmywt7+KlpvWIhy0nIEM8wzndxtKbPr9rcHkv7R0xc+ebxFmAOVwWQFTCxe WxiL3lWzXymFCBuVlDEyOMQDAc8SHEgKpuAZGTkW64GsPjUqwsDu8zLO2DyvzAgLu1pj tYOkwwXQgmZYW3FHjhzjEkzasBb+QKsZAasIKOOtlzPIS0ynPF3U3VCf2lioGDlpE332 0W40qNWrSTvty2RLU8XyRb8iPIjGS57M9Tm5navFXKGogx8h4kytPHcnL1nqMmoO48LC vveF5A808G9oEZWDzYkY9eYJ2c58lEiXZpHg5UOHf6EeWymrrBPTcQowD6NKqYQ+uewr eoGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=XbI2dVps; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bd14si19216302edb.36.2021.09.21.07.21.40; Tue, 21 Sep 2021 07:22:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=XbI2dVps; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S233524AbhIUOVt (ORCPT + 99 others); Tue, 21 Sep 2021 10:21:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233461AbhIUOVs (ORCPT ); Tue, 21 Sep 2021 10:21:48 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECBA4C061574 for ; Tue, 21 Sep 2021 07:20:19 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id b20so23522256lfv.3 for ; Tue, 21 Sep 2021 07:20:19 -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=KI5XuvdO6ZDnwox9e0Y7Y2l7MqmHpltl1BSps4mHQrg=; b=XbI2dVpsQC0cN9/XObORP7B2utE/tgliJMgFY6a5nq/e9gTTy09Booe7LKy8LJTIp/ 45f9oomBvTB5zl3+ERETy15NSiblPZZDu3+UJ1KhKmS93qRaxTrECyqXUVepE2ENpWp0 +RUCb9jWp72wR47J30EtvxOXziru2QQCmILVmpTisLAHoYAR92qbu1kAEKn9/QxOJ9rv nNuXMMdAY3da7jl40DU1r5gHO2NCSzzHjTH0x4isKt0RlOpPKhdodEDx+ImdQtTv1N4p AfHd+JtzcByMLDbyc8kQs8U9qDP6dUdlV3k/atwJ5DWjzAAXJZn3ySU3A+IOdEK3jKEr 7XuQ== 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=KI5XuvdO6ZDnwox9e0Y7Y2l7MqmHpltl1BSps4mHQrg=; b=5X72ZqyQiyS+r/36UsTrJ9Lb4KDES7du4LcmLWDMoN++i5YgNCAOuR5m6v8K6dw7eF PWY+S8UfjVwXqTJlG8IP0g9gjNkUO6weVrRlJAfm1DVS0GQsHPiliIrqo2AMyrEeNrlR 5DHdyt1Ug+yHApEu8+DrqnWN8MeBQu3cXVNMv/bD3n5uQ4i0G3SuI1NmXl5Soqgkt2Q8 1R0jmqv0PHGbVj/ld4dKduK7g773dC9aYNFDQ1g8x4BXLwu3LSHrpbWv6aTZkl+kqSY+ ghVu/kRBvdhM20w76pv4HLhEV6N+4ADI2w8voONpVwbAMpBl/fCZR78knq4MmEw2/82L IBpA== X-Gm-Message-State: AOAM531j2z1wd3Ql3npRK4b/5F6KrUiMEx6O1SfquS/0GGvzX35BRmpg 8UpcIoNXlP4mBcOHbLIE3CNRjdl8csU/Bgrxm3KSvA== X-Received: by 2002:ac2:483b:: with SMTP id 27mr22930494lft.644.1632234015940; Tue, 21 Sep 2021 07:20:15 -0700 (PDT) MIME-Version: 1.0 References: <20210914164727.3007031-1-pgonda@google.com> <20210914164727.3007031-5-pgonda@google.com> In-Reply-To: From: Peter Gonda Date: Tue, 21 Sep 2021 08:20:04 -0600 Message-ID: Subject: Re: [PATCH 4/4 V8] selftest: KVM: Add intra host migration tests To: Marc Orr Cc: kvm list , Sean Christopherson , David Rientjes , Brijesh Singh , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 15, 2021 at 11:28 AM Marc Orr wrote: > > On Tue, Sep 14, 2021 at 9:47 AM Peter Gonda wrote: > > > > Adds testcases for intra host migration for SEV and SEV-ES. Also adds > > locking test to confirm no deadlock exists. > > > > Signed-off-by: Peter Gonda > > Suggested-by: Sean Christopherson > > Reviewed-by: Marc Orr > > Cc: Marc Orr > > Cc: Sean Christopherson > > Cc: David Rientjes > > Cc: Brijesh Singh > > Cc: kvm@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > --- > > tools/testing/selftests/kvm/Makefile | 1 + > > .../selftests/kvm/x86_64/sev_vm_tests.c | 203 ++++++++++++++++++ > > 2 files changed, 204 insertions(+) > > create mode 100644 tools/testing/selftests/kvm/x86_64/sev_vm_tests.c > > > > diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile > > index c103873531e0..44fd3566fb51 100644 > > --- a/tools/testing/selftests/kvm/Makefile > > +++ b/tools/testing/selftests/kvm/Makefile > > @@ -72,6 +72,7 @@ TEST_GEN_PROGS_x86_64 += x86_64/vmx_pmu_msrs_test > > TEST_GEN_PROGS_x86_64 += x86_64/xen_shinfo_test > > TEST_GEN_PROGS_x86_64 += x86_64/xen_vmcall_test > > TEST_GEN_PROGS_x86_64 += x86_64/vmx_pi_mmio_test > > +TEST_GEN_PROGS_x86_64 += x86_64/sev_vm_tests > > TEST_GEN_PROGS_x86_64 += access_tracking_perf_test > > TEST_GEN_PROGS_x86_64 += demand_paging_test > > TEST_GEN_PROGS_x86_64 += dirty_log_test > > diff --git a/tools/testing/selftests/kvm/x86_64/sev_vm_tests.c b/tools/testing/selftests/kvm/x86_64/sev_vm_tests.c > > new file mode 100644 > > index 000000000000..ec3bbc96e73a > > --- /dev/null > > +++ b/tools/testing/selftests/kvm/x86_64/sev_vm_tests.c > > @@ -0,0 +1,203 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "test_util.h" > > +#include "kvm_util.h" > > +#include "processor.h" > > +#include "svm_util.h" > > +#include "kselftest.h" > > +#include "../lib/kvm_util_internal.h" > > + > > +#define SEV_POLICY_ES 0b100 > > + > > +#define NR_MIGRATE_TEST_VCPUS 4 > > +#define NR_MIGRATE_TEST_VMS 3 > > +#define NR_LOCK_TESTING_THREADS 3 > > +#define NR_LOCK_TESTING_ITERATIONS 10000 > > + > > +static void sev_ioctl(int vm_fd, int cmd_id, void *data) > > +{ > > + struct kvm_sev_cmd cmd = { > > + .id = cmd_id, > > + .data = (uint64_t)data, > > + .sev_fd = open_sev_dev_path_or_exit(), > > + }; > > + int ret; > > + > > + ret = ioctl(vm_fd, KVM_MEMORY_ENCRYPT_OP, &cmd); > > + TEST_ASSERT((ret == 0 || cmd.error == SEV_RET_SUCCESS), > > + "%d failed: return code: %d, errno: %d, fw error: %d", > > + cmd_id, ret, errno, cmd.error); > > +} > > + > > +static struct kvm_vm *sev_vm_create(bool es) > > +{ > > + struct kvm_vm *vm; > > + struct kvm_sev_launch_start start = { 0 }; > > + int i; > > + > > + vm = vm_create(VM_MODE_DEFAULT, 0, O_RDWR); > > + sev_ioctl(vm->fd, es ? KVM_SEV_ES_INIT : KVM_SEV_INIT, NULL); > > + for (i = 0; i < NR_MIGRATE_TEST_VCPUS; ++i) > > + vm_vcpu_add(vm, i); > > + if (es) > > + start.policy |= SEV_POLICY_ES; > > + sev_ioctl(vm->fd, KVM_SEV_LAUNCH_START, &start); > > + if (es) > > + sev_ioctl(vm->fd, KVM_SEV_LAUNCH_UPDATE_VMSA, NULL); > > + return vm; > > +} > > I should've suggested this in my original review. But is it worth > moving `sev_vm_create()` and `sev_ioctl()` into the broader selftests > library, so others can leverage this function to write selftests? This function isn't fully complete. It doesn't get to launch_finish, i.e. it only goes far enough for copyless migration ioctls to work. I think this would be a good expansion but could happen in follow up series, thoughts? > > > + > > +static struct kvm_vm *__vm_create(void) > > +{ > > + struct kvm_vm *vm; > > + int i; > > + > > + vm = vm_create(VM_MODE_DEFAULT, 0, O_RDWR); > > + for (i = 0; i < NR_MIGRATE_TEST_VCPUS; ++i) > > + vm_vcpu_add(vm, i); > > + > > + return vm; > > +} > > + > > +static int __sev_migrate_from(int dst_fd, int src_fd) > > +{ > > + struct kvm_enable_cap cap = { > > + .cap = KVM_CAP_VM_MIGRATE_PROTECTED_VM_FROM, > > + .args = { src_fd } > > + }; > > + > > + return ioctl(dst_fd, KVM_ENABLE_CAP, &cap); > > +} > > + > > + > > +static void sev_migrate_from(int dst_fd, int src_fd) > > +{ > > + int ret; > > + > > + ret = __sev_migrate_from(dst_fd, src_fd); > > + TEST_ASSERT(!ret, "Migration failed, ret: %d, errno: %d\n", ret, errno); > > +} > > + > > +static void test_sev_migrate_from(bool es) > > +{ > > + struct kvm_vm *src_vm; > > + struct kvm_vm *dst_vms[NR_MIGRATE_TEST_VMS]; > > + int i; > > + > > + src_vm = sev_vm_create(es); > > + for (i = 0; i < NR_MIGRATE_TEST_VMS; ++i) > > + dst_vms[i] = __vm_create(); > > + > > + /* Initial migration from the src to the first dst. */ > > + sev_migrate_from(dst_vms[0]->fd, src_vm->fd); > > + > > + for (i = 1; i < NR_MIGRATE_TEST_VMS; i++) > > + sev_migrate_from(dst_vms[i]->fd, dst_vms[i - 1]->fd); > > + > > + /* Migrate the guest back to the original VM. */ > > + sev_migrate_from(src_vm->fd, dst_vms[NR_MIGRATE_TEST_VMS - 1]->fd); > > + > > + kvm_vm_free(src_vm); > > + for (i = 0; i < NR_MIGRATE_TEST_VMS; ++i) > > + kvm_vm_free(dst_vms[i]); > > +} > > + > > +struct locking_thread_input { > > + struct kvm_vm *vm; > > + int source_fds[NR_LOCK_TESTING_THREADS]; > > +}; > > + > > +static void *locking_test_thread(void *arg) > > +{ > > + int i, j; > > + struct locking_thread_input *input = (struct locking_test_thread *)arg; > > + > > + for (i = 0; i < NR_LOCK_TESTING_ITERATIONS; ++i) { > > + j = i % NR_LOCK_TESTING_THREADS; > > + __sev_migrate_from(input->vm->fd, input->source_fds[j]); > > + } > > + > > + return NULL; > > +} > > + > > +static void test_sev_migrate_locking(void) > > +{ > > + struct locking_thread_input input[NR_LOCK_TESTING_THREADS]; > > + pthread_t pt[NR_LOCK_TESTING_THREADS]; > > + int i; > > + > > + for (i = 0; i < NR_LOCK_TESTING_THREADS; ++i) { > > + input[i].vm = sev_vm_create(/* es= */ false); > > + input[0].source_fds[i] = input[i].vm->fd; > > + } > > + for (i = 1; i < NR_LOCK_TESTING_THREADS; ++i) > > + memcpy(input[i].source_fds, input[0].source_fds, > > + sizeof(input[i].source_fds)); > > + > > + for (i = 0; i < NR_LOCK_TESTING_THREADS; ++i) > > + pthread_create(&pt[i], NULL, locking_test_thread, &input[i]); > > + > > + for (i = 0; i < NR_LOCK_TESTING_THREADS; ++i) > > + pthread_join(pt[i], NULL); > > +} > > + > > +static void test_sev_migrate_parameters(void) > > +{ > > + struct kvm_vm *sev_vm, *sev_es_vm, *vm_no_vcpu, *vm_no_sev, > > + *sev_es_vm_no_vmsa; > > + int ret; > > + > > + sev_vm = sev_vm_create(/* es= */ false); > > + sev_es_vm = sev_vm_create(/* es= */ true); > > + vm_no_vcpu = vm_create(VM_MODE_DEFAULT, 0, O_RDWR); > > + vm_no_sev = __vm_create(); > > + sev_es_vm_no_vmsa = vm_create(VM_MODE_DEFAULT, 0, O_RDWR); > > + sev_ioctl(sev_es_vm_no_vmsa->fd, KVM_SEV_ES_INIT, NULL); > > + vm_vcpu_add(sev_es_vm_no_vmsa, 1); > > + > > + > > + ret = __sev_migrate_from(sev_vm->fd, sev_es_vm->fd); > > + TEST_ASSERT( > > + ret == -1 && errno == EINVAL, > > + "Should not be able migrate to SEV enabled VM. ret: %d, errno: %d\n", > > + ret, errno); > > + > > + ret = __sev_migrate_from(sev_es_vm->fd, sev_vm->fd); > > + TEST_ASSERT( > > + ret == -1 && errno == EINVAL, > > + "Should not be able migrate to SEV-ES enabled VM. ret: %d, errno: %d\n", > > + ret, errno); > > + > > + ret = __sev_migrate_from(vm_no_vcpu->fd, sev_es_vm->fd); > > + TEST_ASSERT( > > + ret == -1 && errno == EINVAL, > > + "SEV-ES migrations require same number of vCPUS. ret: %d, errno: %d\n", > > + ret, errno); > > How do we know that this failed because `vm_no_vcpu` has no vCPUs or > because it's not a SEV-ES VM? Actually with V8 we only migrate to none SEV(-ES)? enabled guests. > > > + > > + ret = __sev_migrate_from(vm_no_vcpu->fd, sev_es_vm_no_vmsa->fd); > > + TEST_ASSERT( > > + ret == -1 && errno == EINVAL, > > + "SEV-ES migrations require UPDATE_VMSA. ret %d, errno: %d\n", > > + ret, errno); > > Same question. How do we know why this failed? `sev_es_vm_no_vmsa` did > not have any vCPUs added. Would it be cleaner to add an additional > param to `sev_vm_create()` to skip calling UPDATE_VMSA? Then, > `sev_es_vm_no_vmsa` can be created from `sev_vm_create()` and it's > obvious to the read that the VMs are identical except for this aspect. > > > + > > + ret = __sev_migrate_from(vm_no_vcpu->fd, vm_no_sev->fd); > > + TEST_ASSERT(ret == -1 && errno == EINVAL, > > + "Migrations require SEV enabled. ret %d, errno: %d\n", ret, > > + errno); > > `vm_no_sev` has vCPUs. Therefore, how do we know why this failed -- > (a) differing vCPU counts or (b) no SEV? Ditto we require dst to be none SEV enabled. > > > +} > > + > > +int main(int argc, char *argv[]) > > +{ > > + test_sev_migrate_from(/* es= */ false); > > + test_sev_migrate_from(/* es= */ true); > > + test_sev_migrate_locking(); > > + test_sev_migrate_parameters(); > > + return 0; > > +} > > -- > > 2.33.0.309.g3052b89438-goog > >