From: Peter Gonda <pgonda@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm list <kvm@vger.kernel.org>, Marc Orr <marcorr@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
David Rientjes <rientjes@google.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Singh, Brijesh" <brijesh.singh@amd.com>,
Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2 V7] Add AMD SEV and SEV-ES intra host migration support
Date: Thu, 2 Sep 2021 12:53:13 -0600 [thread overview]
Message-ID: <CAMkAt6rAnftQvtiu3bF+TUBEELucrZ+GmD83s+Y_3T3hPaLv6w@mail.gmail.com> (raw)
In-Reply-To: <YTEbyYilbrLL9JSV@google.com>
On Thu, Sep 2, 2021 at 12:45 PM Sean Christopherson <seanjc@google.com> wrote:
>
> Please Cc the cover letter to anyone that was Cc'd on one or more patches. That's
> especially helpful if some recipients aren't subscribed to KVM. Oh, and Cc lkml
> as well, otherwise I believe lore, patchwork, etc... won't have the cover letter.
Add CCs here. Thanks.
>
> On Thu, Sep 02, 2021, Peter Gonda wrote:
> > 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).
> >
> > For the intra host operation the SEV required metadata, the source VM FD is
> > sent to the target VMM. The target VMM calls the new cap ioctl with the
> > source VM FD, KVM then moves all the SEV state to the target VM from the
> > source VM.
prev parent reply other threads:[~2021-09-02 18:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210902181751.252227-1-pgonda@google.com>
2021-09-02 18:17 ` [PATCH 1/3 V7] KVM, SEV: Add support for SEV intra host migration Peter Gonda
2021-09-10 0:11 ` Sean Christopherson
2021-09-10 1:12 ` Sean Christopherson
2021-09-13 16:21 ` Peter Gonda
2021-09-10 1:15 ` Marc Orr
2021-09-10 1:40 ` Sean Christopherson
2021-09-10 3:41 ` Marc Orr
2021-09-10 21:54 ` Peter Gonda
2021-09-10 22:03 ` Sean Christopherson
2021-09-10 22:07 ` Peter Gonda
2021-09-02 18:17 ` [PATCH 2/3 V7] KVM, SEV: Add support for SEV-ES " Peter Gonda
2021-09-10 0:50 ` Sean Christopherson
2021-09-10 1:20 ` Sean Christopherson
2021-09-02 18:17 ` [PATCH 3/3 V7] selftest: KVM: Add intra host migration tests Peter Gonda
2021-09-10 17:16 ` Sean Christopherson
2021-09-10 22:14 ` Peter Gonda
[not found] ` <YTEbyYilbrLL9JSV@google.com>
2021-09-02 18:53 ` Peter Gonda [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMkAt6rAnftQvtiu3bF+TUBEELucrZ+GmD83s+Y_3T3hPaLv6w@mail.gmail.com \
--to=pgonda@google.com \
--cc=brijesh.singh@amd.com \
--cc=dgilbert@redhat.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcorr@google.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rientjes@google.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).