lkml.org 
[lkml]   [2021]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    Subject[PATCH 0/3] Add AMD SEV and SEV-ES local migration support
    From
    Local 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 move a guest to a new host, local 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 using /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 local 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).

    During the local send operation the SEV required metadata, the guest's
    ASID is loaded into a kvm wide hashmap keyed by a value given by
    userspace. This allows the userspace VMM to pass the key to the target
    VMM. Then on local receive the target VMM can be loaded with the
    metadata from the hashmap.

    Peter Gonda (3):
    KVM, SEV: Refactor out function for unregistering encrypted regions
    KVM, SEV: Add support for SEV local migration
    KVM, SEV: Add support for SEV-ES local migration

    .../virt/kvm/amd-memory-encryption.rst | 43 ++
    arch/x86/kvm/svm/sev.c | 434 +++++++++++++++++-
    arch/x86/kvm/svm/svm.h | 1 +
    include/uapi/linux/kvm.h | 12 +
    4 files changed, 471 insertions(+), 19 deletions(-)

    base-commit: f1b832550832

    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Cc: Brijesh Singh <brijesh.singh@amd.com>
    Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
    Cc: Wanpeng Li <wanpengli@tencent.com>
    Cc: Jim Mattson <jmattson@google.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: kvm@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org

    --
    2.32.0.288.g62a8d224e6-goog

    \
     
     \ /
      Last update: 2021-06-21 18:59    [W:2.893 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site