Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4637985pxb; Tue, 5 Oct 2021 07:19:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwll8n2PeO6bNLdhqQPRGraJtmIMa62Y8YlfeifMaeF5P3d5IXQeQgcfI0hN3UwfOfQTW85 X-Received: by 2002:aa7:c911:: with SMTP id b17mr17404850edt.5.1633443590123; Tue, 05 Oct 2021 07:19:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633443590; cv=none; d=google.com; s=arc-20160816; b=wHOTJlwnxXPEmJTwkW3lxoZ2eXjLUDyecFwJG9JXfV/aEiPNPyCJ/omodSksIwkE7Z jYxtLkEYn8tcBAh5tSxO29PciGtlZ9S6ERsoVfnRckG8by506/uhIWWgXwP9EOWj3Bug EySzUz80BALR2IpsMrKCZaD+m4bJM2g8UgY3DETpUPNjKmeKax1JbcbKt3tIY7u8UBgJ nC6zOtm2UPZGgMVPHjFJLAtFw1hxHqr/xdmky3zSFhdDuaA0N8c/DVQiDabsLjUH4R8d aGrdzygCDnq2WNDq8DEgs2JPk5Nhdr1or38bIgYFeB5tbce9FbBL4xEsGdD7oHUBN1X5 jD3w== 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:mime-version:message-id:date :dkim-signature; bh=SDsJgC6yRUYCiS38hXuTRfkxBXO2Typ8HW1RqnSDwgU=; b=fBjgldIFoJ5amoZeX3ghXEznpgM3qcLXxwB32JnW55Kxt1pTfEObmgmFtZYKI7XSVE s4F25JHXaSU5V/u9juf0nydf6LjOFTPQzp3hP903psOqR+4A6xzYl8Lfyb6gxR18Jri7 JUcaTcZZq+0ytGPpvgVZPfYNkZBrQeruIMcLqmNMhMSVGgTQ9eBfFXf+Rupb4l55kk5Y GEOX2qA7MIn83b3ifU/kq6dG9Q7JuRD4tX3C+Tkw8/gylFdaZ+lCP7GBQsUDqszRqcD8 Dl4oIoCxyQ/nJKcSdQ2MZ3Z8ysI3CGyoo6T16czTkIPVhYjj8gawQYg2Vsts66xd4Sp/ m99g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=WeZkwfK6; 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 18si20655415ejj.476.2021.10.05.07.19.22; Tue, 05 Oct 2021 07:19:50 -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=WeZkwfK6; 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 S236063AbhJEOQ7 (ORCPT + 99 others); Tue, 5 Oct 2021 10:16:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235132AbhJEOQx (ORCPT ); Tue, 5 Oct 2021 10:16:53 -0400 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4EF4C061760 for ; Tue, 5 Oct 2021 07:14:06 -0700 (PDT) Received: by mail-pf1-x449.google.com with SMTP id i3-20020aa79083000000b003efb4fd360dso8141368pfa.8 for ; Tue, 05 Oct 2021 07:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:message-id:mime-version:subject:from:to:cc; bh=SDsJgC6yRUYCiS38hXuTRfkxBXO2Typ8HW1RqnSDwgU=; b=WeZkwfK6oBSxs/O/acgLPndgpCiFPCqd4RXHGlMyqTy0KCNAgjQIOFHL1HHsn5GKG8 F6L3/f5shsb/QdXjg22u39OY9tRhTOl6TgwBnJnWyzYPMdkxJrZn6r9zhXnamfzYF61U k1bpJJkJ0IglQ0M93cIay60PqMgDxk0abkZLyqtBpAbTOsDKOFqgFBwDimxGj1qofayn GHmYtuDVmc4jwjZDjmzkC22clpPR4u/mpOsOLZOvuDOG8fhiYSIXlGMZ3Z0afMpC3LXz xS+g83DJUtbIyoDP13E/PXSakvBhBxbAYvrJxkMYnqbiI3nl0D45aU0K5tgAfMG4UhbT 0YtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=SDsJgC6yRUYCiS38hXuTRfkxBXO2Typ8HW1RqnSDwgU=; b=KeL4zDoD6g2uVeeD3xRHCh1dKw30860c4scr4BWKylEOSjEg99EFIanAs04ZNk9egF Hob2QjKSRTDs+dY5T6JBHTH0UsYp6Nj5vVkNY5mWlj9nL20yYqAe8Vzae/XZkP5pifod fpUKk1B7iBU+p7jlERULBTVyKrJ7zT1H5+B8kLcpzSywm0OSpfmQUUJf1cWyFSqIsGj0 UwHUt9coM0MVRt9y5+hcMPUIzEOEniDdq/4+nPrBwdj5iD0nqOEryOkHToVfM+WbPyW8 bCwaLn2hw4qLsRkND5FW1l8GZWSQdQD4s9z+2O4iB3fiSXR69m29blEfUabWyPbuTkXd Q0jA== X-Gm-Message-State: AOAM530AtgEjKIgScQAT6fg4P3cePZl9yyHUnNUqAPa8hl8JqrPUZ4oC LPWRxuatE+4pFMm/Gyg0uKf0hstFavU= X-Received: from pgonda1.kir.corp.google.com ([2620:15c:29:204:225f:7216:6111:7f1c]) (user=pgonda job=sendgmr) by 2002:a17:90a:7892:: with SMTP id x18mr4058151pjk.33.1633443246156; Tue, 05 Oct 2021 07:14:06 -0700 (PDT) Date: Tue, 5 Oct 2021 07:13:53 -0700 Message-Id: <20211005141357.2393627-1-pgonda@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.33.0.800.g4c38ced690-goog Subject: [PATCH 0/4 V9] Add AMD SEV and SEV-ES intra host migration support From: Peter Gonda To: kvm@vger.kernel.org Cc: Peter Gonda , Marc Orr , Paolo Bonzini , Sean Christopherson , David Rientjes , "Dr . David Alan Gilbert" , Brijesh Singh , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Intra host migration provides a low-cost mechanism for userspace VMM upgrades. It is an alternative to traditional (i.e., remote) live migration. Whereas remote migration handles moving a guest to a new host, intra host migration only handles moving a guest to a new userspace VMM within a host. This can be used to update, rollback, change flags of the VMM, etc. The lower cost compared to live migration comes from the fact that the guest's memory does not need to be copied between processes. A handle to the guest memory simply gets passed to the new VMM, this could be done via /dev/shm with share=on or similar feature. The guest state can be transferred from an old VMM to a new VMM as follows: 1. Export guest state from KVM to the old user-space VMM via a getter user-space/kernel API 2. Transfer guest state from old VMM to new VMM via IPC communication 3. Import guest state into KVM from the new user-space VMM via a setter user-space/kernel API VMMs by exporting from KVM using getters, sending that data to the new VMM, then setting it again in KVM. In the common case for intra host migration, we can rely on the normal ioctls for passing data from one VMM to the next. SEV, SEV-ES, and other confidential compute environments make most of this information opaque, and render KVM ioctls such as "KVM_GET_REGS" irrelevant. As a result, we need the ability to pass this opaque metadata from one VMM to the next. The easiest way to do this is to leave this data in the kernel, and transfer ownership of the metadata from one KVM VM (or vCPU) to the next. For example, we need to move the SEV enabled ASID, VMSAs, and GHCB metadata from one VMM to the next. In general, we need to be able to hand off any data that would be unsafe/impossible for the kernel to hand directly to userspace (and cannot be reproduced using data that can be handed safely to userspace). V9 * Fix sev_lock_vcpus_for_migration from unlocking the vCPU mutex it failed to unlock. V8 * Update to require that @dst is not SEV or SEV-ES enabled. * Address selftest feedback. V7 * Address selftest feedback. V6 * Add selftest. V5: * Fix up locking scheme * Address marcorr@ comments. V4: * Move to seanjc@'s suggestion of source VM FD based single ioctl design. v3: * Fix memory leak found by dan.carpenter@ v2: * Added marcorr@ reviewed by tag * Renamed function introduced in 1/3 * Edited with seanjc@'s review comments ** Cleaned up WARN usage ** Userspace makes random token now * Edited with brijesh.singh@'s review comments ** Checks for different LAUNCH_* states in send function v1: https://lore.kernel.org/kvm/20210621163118.1040170-1-pgonda@google.com/ base-commit: 680c7e3be6a3 Cc: Marc Orr Cc: Paolo Bonzini Cc: Sean Christopherson Cc: David Rientjes Cc: Dr. David Alan Gilbert Cc: Brijesh Singh Cc: Vitaly Kuznetsov Cc: Wanpeng Li Cc: Jim Mattson Cc: Joerg Roedel Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Peter Gonda (4): KVM: SEV: Add support for SEV intra host migration KVM: SEV: Add support for SEV-ES intra host migration selftest: KVM: Add open sev dev helper selftest: KVM: Add intra host migration tests Documentation/virt/kvm/api.rst | 15 ++ arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/svm/sev.c | 187 ++++++++++++++++ arch/x86/kvm/svm/svm.c | 1 + arch/x86/kvm/svm/svm.h | 2 + arch/x86/kvm/x86.c | 6 + include/uapi/linux/kvm.h | 1 + tools/testing/selftests/kvm/Makefile | 1 + .../testing/selftests/kvm/include/kvm_util.h | 1 + .../selftests/kvm/include/x86_64/svm_util.h | 2 + tools/testing/selftests/kvm/lib/kvm_util.c | 24 ++- tools/testing/selftests/kvm/lib/x86_64/svm.c | 13 ++ .../selftests/kvm/x86_64/sev_vm_tests.c | 203 ++++++++++++++++++ 13 files changed, 447 insertions(+), 10 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/sev_vm_tests.c -- 2.33.0.309.g3052b89438-goog