Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp638212pxb; Wed, 22 Sep 2021 09:36:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGomDAVP4OW+V8dk5t0UXQrpa1dIlQL2PKN8xata2GwnlgPEUcVSruiprl/X94zkHJEql2 X-Received: by 2002:a05:6638:2050:: with SMTP id t16mr612786jaj.101.1632328561899; Wed, 22 Sep 2021 09:36:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632328561; cv=none; d=google.com; s=arc-20160816; b=g3KlDewBEn+hE5qekccfsGeaVexCyBxShlyQbDBopMZFzH5n6i2BJd0x7VKbiuAB5y JN+jEck4zfUA2XC/xjhJ2n/lv12Badn2Qm5ZUdTXik2/J1Q+g2EGY3NjuAC6dpe2SlxR eVAs+MY6L6QRIZN78buMNyoDHiI9L//zI2izpwglBp1s605//jPTvq2Veaf2B/YBpj7S 3GlY4CR9brd5ZKcbc5A0lw2X8pZbui3WL2WnuzMIkF0lwemcGbiyrDeTZet94FvbdjQq 6pA7a116sckTYmvyRV8RG2IGsmYAgQnjJOwd3ol01l0kUXZiyz/RvlQuTIa+XQXE8Zcx 3t9g== 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=m6J+OkKKPxNvNc7nO5L1z2FUZYCyj9JJhrvRz003S+U=; b=xI3nK1FGKplWuypo3UaZlOkCEkH8Jam7G3oxn/CoqBDIj9FhiIRaMktmvWwzlqvm9O auXdj1+ILTJGCY2Ml6a6y19K5WTBdA6b9XM8AZk74WiAvPajvOLYOrpKr6wHK2/a5bLL 4d8mVMTDRJDvCahqa2j2nEhgLgMtYx2oyqVazfPaPYVYZ9pghMgd0pLuAc5Nzvu/jsyu p/ho5d8LqsEPSxBvcaQs6JpP/smRzII49e/IsOGHRU747flRBjTdCvpixCAA+P8YMNcK L5IWOrFR6VBgI0R0xvfQYOFXxDFYpurX+JI5oF/7cxR58heeJ8thLjAaZE7kzxl+4zAf vLGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KTSra+1i; 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 y6si2927101ioy.30.2021.09.22.09.35.36; Wed, 22 Sep 2021 09:36:01 -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=KTSra+1i; 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 S236652AbhIVQgL (ORCPT + 99 others); Wed, 22 Sep 2021 12:36:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236597AbhIVQgK (ORCPT ); Wed, 22 Sep 2021 12:36:10 -0400 Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A6D9C061574 for ; Wed, 22 Sep 2021 09:34:40 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id 67-20020a9d0449000000b00546e5a8062aso4272146otc.9 for ; Wed, 22 Sep 2021 09:34:40 -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=m6J+OkKKPxNvNc7nO5L1z2FUZYCyj9JJhrvRz003S+U=; b=KTSra+1iGuvxVBVCe4ILUIzFlth9B3j2n/GFGQNJo5DLFuOAYLrvj2AoM8h+VbX+am 8qoH0YApr7O78kvVJZonmSel+O+s8fKvDu9BDDQ95gsIGEh+ydOuMdAU/LEU1nUg5tn8 QBKKa6Kbmwc5fKraW3iX+ugFWEvK/2+ulRlTa6tMD8U6PoCVY1T/ZMMbTAZebfD5J8Vd tEKEnwY4xS4OC5IPMBbPSFv7ogkPSotRCfQKauaaBc+krBS30Vna93d2v+Z3XizrPHq8 TBYXGUAJwxF25cVtFPHVagzTLCTTereQBGkkX9PTzfHVbAtJoLOYml4d7HBHbhupjRK9 RMYw== 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=m6J+OkKKPxNvNc7nO5L1z2FUZYCyj9JJhrvRz003S+U=; b=BYHbkr+/5LzlRM+7OUPvCU6SLXzaO92dorrdUVycRSzS+6QGE8S+ooVpo04ROpoPYS +73dToHnzymalQpheexNXIUSEBJaWPgpjZktTHtf47/SUMvUakYFrsaAI1gqc2evOmuq De8nRHtmgDtOF9Ihz6AqylSd+CVIkuUzhopjg7KQZiwxB4XkCNhvCtcBl/ZkckXqWh+r rLj7hcIgSa068g+Oq2btsHQHt4VN0YqeU9/p3ikKTX5ZlbumoIrINU/qQXh2rHfUtgz1 PYng1QSbsxSO9iQ+DSMX1cE9qdIzKcwn0nIz490bzXJfFBKOqeoPsCE8tRLp1aAEWALP sW4Q== X-Gm-Message-State: AOAM5324rGv7PNxRvMecQ2YT5kf7LV5S/um4Q80fl9XVV2cvE1NlIIdO Lbg/u5gpAldBnE3bOq2ItjvWrnHrnTivZBF/DLBuqQ== X-Received: by 2002:a05:6830:2b27:: with SMTP id l39mr20125otv.25.1632328479385; Wed, 22 Sep 2021 09:34:39 -0700 (PDT) MIME-Version: 1.0 References: <20210914164727.3007031-1-pgonda@google.com> <20210914164727.3007031-5-pgonda@google.com> In-Reply-To: From: Marc Orr Date: Wed, 22 Sep 2021 09:34:28 -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 21, 2021 at 7:20 AM Peter Gonda wrote: > > 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? SGTM. Let's leave it here for now then. > > > > > > + > > > +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. I think my point is that the test case should be written to treat the underlying KVM code as a black box. Without looking at the KVM code, the test case should be setup to be accepted perfectly by KVM and then mutated in a minimal way to trigger the intended failure case. Here, we've defined `vm_no_vcpu`, which as far as I can tell is: (1) not a SEV VM, (2) not a SEV-ES VM, (3) has no vCPUs. Based on the error message in the TEST_ASSERT, the intention here is to verify that a migration that would otherwise works, fails because the target has a different number of vCPUs than the source. Therefore, I think `vm_no_vcpu` should be defined as a SEV-ES VM, so that the test case is setup such that it would've otherwise passed if `vm_no_vcpu` had the correct number of vCPUs added. > > > > > > + > > > + 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. Understood. But I think the test should treat KVM as a black box. Therefore, I think in this test case, `vm_no_vcpu` should be defined to have the same number of vCPUs as `vm_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 > > >