Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp858007pxb; Thu, 21 Oct 2021 10:47:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywyy0dY+LPZZa3AFxDJ9s8MvoAff+No759oNxW5wCR1hNzzhstKFt3oSU0LMW0UuN+4lO6 X-Received: by 2002:a17:90b:4d0b:: with SMTP id mw11mr8415372pjb.228.1634838466064; Thu, 21 Oct 2021 10:47:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634838466; cv=none; d=google.com; s=arc-20160816; b=LaRQdGYLtaKscwa1Hia77K3Bb4/zbVaZnsgX9MITGIfZVqkdgdmxkxSMq5i3E4nQ8F FeMY1OevYji0Uki78gwEETed5zvBcmCExpttLkdzJR0NA+RCNA+5qznGu6UDbh4zOAuF D+r4rVnBVqg55Yv+qwoTggePLmyZtiajFdf3/njmCVb+tqCS8IHk4NYqh8KMal6CaMab J1rs3DsExfm6WvZV2m74/RJtMJenGQ2n6mAGIyI3+tlX3fntS2uqZ7GhdwzTpKJCfqkS xeonbIT1kgTffdlUMS7W6iW42utBu06GpwJF/xBYwwKcPT2bOk0eiuXeWgQIYz3ZfpJO viNw== 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=iURUGf0w78yycZlu3miQkJiEIuDMDSn6yRxhCauMXZs=; b=tGu70vCe2AMteG+iklrw9XhvY1lpk1WROJvVK0LyiZ8exEQ30GjvXrngjT4dp6TFKW zzaRKMRlFdjrmamKYWuQw6tcJEWRI4mn0EtAaTi6D7h6Y8LEQ8d6aVd72Xb48foRW7LC gG3OLAq01PVT6yKShGee1BJX1yrU+JHCZinZ4KKKuUAuqlDkFcOvDT2eq900Py6zSmLm AzfJ1mzu5eY94B6RwiWWzW454REggRaJkk1QgbONqRDELoT6gaeSVY2b+lz+YN2y29Mg wV8C20vvCfNSiwYlsidjL8aDBAo8MTry+7tCbHQFjn+0er0gRb7GuPv+v8yxNf+DNV/P KPDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=FYDdF7Pw; 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 4si7070790pli.173.2021.10.21.10.47.33; Thu, 21 Oct 2021 10:47:46 -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=FYDdF7Pw; 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 S232209AbhJURrb (ORCPT + 99 others); Thu, 21 Oct 2021 13:47:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232520AbhJURqq (ORCPT ); Thu, 21 Oct 2021 13:46:46 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48BD1C0432C3 for ; Thu, 21 Oct 2021 10:43:07 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id k1-20020a170902c40100b0013f47bac4d8so535601plk.14 for ; Thu, 21 Oct 2021 10:43:07 -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=iURUGf0w78yycZlu3miQkJiEIuDMDSn6yRxhCauMXZs=; b=FYDdF7PwrythipcCGhs6ak63WyihVhH3l9X3Mdqn78QcJkg71mr/Yb5C5rXAxakXf+ XjQDJngrHupRI+gfUqt52vbengOSjCZlNM7D/0PW77dJpdQrUVjxZFTZz+8ynEzMmI11 lss2UFhFeBB+TubSLlFEIAfwE1fFnWDmRzLF31D2RW30W41849OY6XUO5eVcczFVfOwC CuV+jHxy7l9mp4hg81m6Mdnm8Gy0/whoZnjhZcDsi+cJPxtuTXAcZ1ob0ZgXqAbd5Dhn lOcCfc4rubjMWfsKNJ0OA1p8VDc86P3N+pWanZ8d/xJAW3uWEG/iIrLyXlFFlxIp4iy4 O+Tw== 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=iURUGf0w78yycZlu3miQkJiEIuDMDSn6yRxhCauMXZs=; b=aafgIGcA0MCokQRJuRTSlsOECjDWxIZ2IGVF3qkvgMrrPTi6uNrWYA4y7IzKpUIagb 5csFgfEA4GsyphXXRdVLuAUaSAzxmazkkCqPFJJ1Y/TDkq951txrHuvS3ffK5BbIHQtU zybiT2hESAaXd5aPGnAsIpQ3tXlwS4pMmf9LU1cRDLb8dcGcYhY97p7KgZZKIKtWQqIN uWJkENQZ41nv9/HLDG5mDKOk3ii5+x7eJoET4WoCNsF1qpSw5jPe6KyXCxytGtC+okjC 5AuK1o7xlzEdiT0JKaQecXifjJW5gfncCimBmNTMjk+QBPwZVDAQJBUiUIJGe8khhh4w XQbQ== X-Gm-Message-State: AOAM531YPNNLkButKtol+41Zb5C14XPqJwePOP12qFVB2Uz2zwTJR/4R bIE5/Ru3hHdV3FOEyf85D5VBy6ugQYw= X-Received: from pgonda1.kir.corp.google.com ([2620:15c:29:204:da2d:dcb2:6:add9]) (user=pgonda job=sendgmr) by 2002:a63:7b4a:: with SMTP id k10mr5515192pgn.301.1634838186675; Thu, 21 Oct 2021 10:43:06 -0700 (PDT) Date: Thu, 21 Oct 2021 10:42:58 -0700 Message-Id: <20211021174303.385706-1-pgonda@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.33.0.1079.g6e70778dc9-goog Subject: [PATCH 0/5 V11] 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 , Tom Lendacky , 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). V11 * Zero SEV-ES vCPU state on source. * Rebase onto SEV-ES fixes. V10 * Add new starting patch to refactor all SEV-ES related vCPU data into for easier copying. 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: 9f1ee7b169af Cc: Marc Orr Cc: Paolo Bonzini Cc: Sean Christopherson Cc: David Rientjes Cc: Dr. David Alan Gilbert Cc: Brijesh Singh Cc: Tom Lendacky 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 (5): Refactor out sev_es_state struct 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 | 268 +++++++++++++++--- arch/x86/kvm/svm/svm.c | 9 +- arch/x86/kvm/svm/svm.h | 28 +- arch/x86/kvm/x86.c | 6 + include/uapi/linux/kvm.h | 1 + tools/testing/selftests/kvm/Makefile | 3 +- .../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, 507 insertions(+), 67 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/sev_vm_tests.c -- 2.33.0.1079.g6e70778dc9-goog