Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp676771pxb; Wed, 15 Sep 2021 10:29:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJww/E6O0osTI3Jrq9jq95qkBw1KyFPC002xk6weJjHC1GDqWZBLql4nKAaUcObv1/eYI6wl X-Received: by 2002:a05:6402:510f:: with SMTP id m15mr1200996edd.257.1631726983621; Wed, 15 Sep 2021 10:29:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631726983; cv=none; d=google.com; s=arc-20160816; b=xNHgIDI41CReDVD13jKXGmH76+FdzlgDkFTNLCXMtQShcXbm0uNrOU/IGZ/NDseqCS hXHGsTdCbX3hP2Q9y+EILEhX0Djf4Ztu7O8yZg45y+qe+/GGGRtq9pI9jjt60W2bD6DE JihPpBI6i4OzMZYzH+SQQosHe1I/TL+Vx+6mjdVTZVdlZNad7o6jv7xl6odp52Ytd0Iy iD8/FYb4KR4mZT+hLY5BpXggk9jl0l81EE5Y2H4taeAvWqVGIxCg8I5iJNn92eu27WzE gHSLJ16Sgjrjmz6fbpeIDNyty1RZld6JXUJRXn575KyVlmYVlOMgmV9KIfmLmd+HsQiE Uy4A== 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=c8zUWKPUgTZABevow7z0k9jmN0O/6BSh3As22IG3b64=; b=I4Ervd/PI+qAMncZ/hPWirB1yzh7W8X4QEvHYwjN2CPHQCRW0HoGNYnxDmpFQqdtcw eA5yqKuhCxlf3d5wAnrG33cFDm1JIPJgHNGHo/l873DuBF/S9DI5UldtUkKEaGGl27Gi EVNZ0DsPy2TLjrj06Vjxp0JmSdo0SBksZs0ze3nUTI5kV5ejI/v7YIz+iykpWtiUgjuY o5Q6GRZZHmtQRsSxAu4nafqPGa4DivsdIUw7kal2hwPRjEJk13JltA2Jt15W3MVi1OCp q0u/cYCT052g6NIm3oPrDIJ+lXouP9IV85rbW13ay1LQNgZRH9MAVjl3incEbrKT8u7q YH+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="HAQH5/gG"; 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 hy1si560627ejc.545.2021.09.15.10.29.19; Wed, 15 Sep 2021 10:29:43 -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="HAQH5/gG"; 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 S229738AbhIOR3U (ORCPT + 99 others); Wed, 15 Sep 2021 13:29:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229479AbhIOR3U (ORCPT ); Wed, 15 Sep 2021 13:29:20 -0400 Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 218D0C061574 for ; Wed, 15 Sep 2021 10:28:01 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id o66so2494615oib.11 for ; Wed, 15 Sep 2021 10:28:01 -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=c8zUWKPUgTZABevow7z0k9jmN0O/6BSh3As22IG3b64=; b=HAQH5/gGAxa+81crhk6Hx+MOwpYF5prlm2W2nAqX3OrwZ7nZHGBLGgcgBrlJf6ETj2 6+O5wNpcOeHihQDP1EVLq2UiXVqrVSdcd24zqkTsVd8ARmlBtWlzVdAOKWfAPQQVS37z LM2Rp8oxN6EYiLS2lmYRdwLu4BKEsTdwhTBg7vm34JZY98QdljfTChACENIlLDTlU0Lt n1O8dgRZSvQ/ziR7P9Bygq6ivU2cSuV6MNOLjS2r/GdQVYQNG2zCtdHhmHcS56jYVsiv CDijH1owZ+IWe8ptp8hs+c5xlDPeHOfp+qLUkteSU5yEh19EJpPqdA3a7G3AvziBGdeT h1Rg== 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=c8zUWKPUgTZABevow7z0k9jmN0O/6BSh3As22IG3b64=; b=n3F5Z7EW0edy1d/IvJ3F23cqvowuwNA6had10MeEr61XYERxZkHw9G3o2Ul+sEpewz r6JjEELdAHkXRw2DDDOMhk1ommoCNUt3zfqzksT89obNcMS43OwTAvYUsQXWZSS6igfc FsEU9520Tx8OihdB9BvJPgPmMmJ2DDoxxXdqvzzXON8u2kKuOTTqPHSEv9+eLusA1pXa WaDpmCtda9dBjtgUoADcuOOLaMxMm7DIwCpAM2lBdeKkT0Pfkb2Os80NGEkXL0c7PcAq 4D9bMEnCzqGVX3UsJC9M7Gl+NeP9BvP9g+sm88IjjYbATYdC+yS6mx8thig0CqLcNcwh upCw== X-Gm-Message-State: AOAM53262qYyRRWOsc3IVNBPJ7wEccM6kmegyiwCddmEpHtYOM4MLAVT DzHsaxwFXEfQwF+wfvY7AnnXmKjNKewh1oyV1hp7uQ== X-Received: by 2002:a05:6808:21a5:: with SMTP id be37mr606899oib.172.1631726880229; Wed, 15 Sep 2021 10:28:00 -0700 (PDT) MIME-Version: 1.0 References: <20210914164727.3007031-1-pgonda@google.com> <20210914164727.3007031-5-pgonda@google.com> In-Reply-To: <20210914164727.3007031-5-pgonda@google.com> From: Marc Orr Date: Wed, 15 Sep 2021 10:27:49 -0700 Message-ID: Subject: Re: [PATCH 4/4 V8] selftest: KVM: Add intra host migration tests To: Peter Gonda 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 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? > + > +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? > + > + 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? > +} > + > +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 >