From: Sean Christopherson <seanjc@google.com>
To: Ashish Kalra <ashish.kalra@amd.com>
Cc: Steve Rutherford <srutherford@google.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"venu.busireddy@oracle.com" <venu.busireddy@oracle.com>,
"Singh, Brijesh" <brijesh.singh@amd.com>,
Will Deacon <will@kernel.org>,
Quentin Perret <qperret@google.com>
Subject: Re: [PATCH v10 10/16] KVM: x86: Introduce KVM_GET_SHARED_PAGES_LIST ioctl
Date: Fri, 26 Feb 2021 09:44:41 -0800 [thread overview]
Message-ID: <YDkzibkC7tAYbfFQ@google.com> (raw)
In-Reply-To: <20210226140432.GB5950@ashkalra_ubuntu_server>
+Will and Quentin (arm64)
Moving the non-KVM x86 folks to bcc, I don't they care about KVM details at this
point.
On Fri, Feb 26, 2021, Ashish Kalra wrote:
> On Thu, Feb 25, 2021 at 02:59:27PM -0800, Steve Rutherford wrote:
> > On Thu, Feb 25, 2021 at 12:20 PM Ashish Kalra <ashish.kalra@amd.com> wrote:
> > Thanks for grabbing the data!
> >
> > I am fine with both paths. Sean has stated an explicit desire for
> > hypercall exiting, so I think that would be the current consensus.
Yep, though it'd be good to get Paolo's input, too.
> > If we want to do hypercall exiting, this should be in a follow-up
> > series where we implement something more generic, e.g. a hypercall
> > exiting bitmap or hypercall exit list. If we are taking the hypercall
> > exit route, we can drop the kvm side of the hypercall.
I don't think this is a good candidate for arbitrary hypercall interception. Or
rather, I think hypercall interception should be an orthogonal implementation.
The guest, including guest firmware, needs to be aware that the hypercall is
supported, and the ABI needs to be well-defined. Relying on userspace VMMs to
implement a common ABI is an unnecessary risk.
We could make KVM's default behavior be a nop, i.e. have KVM enforce the ABI but
require further VMM intervention. But, I just don't see the point, it would
save only a few lines of code. It would also limit what KVM could do in the
future, e.g. if KVM wanted to do its own bookkeeping _and_ exit to userspace,
then mandatory interception would essentially make it impossible for KVM to do
bookkeeping while still honoring the interception request.
However, I do think it would make sense to have the userspace exit be a generic
exit type. But hey, we already have the necessary ABI defined for that! It's
just not used anywhere.
/* KVM_EXIT_HYPERCALL */
struct {
__u64 nr;
__u64 args[6];
__u64 ret;
__u32 longmode;
__u32 pad;
} hypercall;
> > Userspace could also handle the MSR using MSR filters (would need to
> > confirm that). Then userspace could also be in control of the cpuid bit.
An MSR is not a great fit; it's x86 specific and limited to 64 bits of data.
The data limitation could be fudged by shoving data into non-standard GPRs, but
that will result in truly heinous guest code, and extensibility issues.
The data limitation is a moot point, because the x86-only thing is a deal
breaker. arm64's pKVM work has a near-identical use case for a guest to share
memory with a host. I can't think of a clever way to avoid having to support
TDX's and SNP's hypervisor-agnostic variants, but we can at least not have
multiple KVM variants.
> > Essentially, I think you could drop most of the host kernel work if
> > there were generic support for hypercall exiting. Then userspace would
> > be responsible for all of that. Thoughts on this?
> So if i understand it correctly, i will submitting v11 of this patch-set
> with in-kernel support for page encryption status hypercalls and shared
> pages list and the userspace control of SEV live migration feature
> support and fixes for MSR handling.
At this point, I'd say hold off on putting more effort into an implementation
until we have consensus.
> In subsequent follow-up patches we will add generic support for hypercall
> exiting and then drop kvm side of hypercall and also add userspace
> support for MSR handling.
>
> Thanks,
> Ashish
next prev parent reply other threads:[~2021-02-26 17:45 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-04 0:35 [PATCH v10 00/17] Add AMD SEV guest live migration support Ashish Kalra
2021-02-04 0:36 ` [PATCH v10 01/16] KVM: SVM: Add KVM_SEV SEND_START command Ashish Kalra
2021-02-04 0:36 ` [PATCH v10 02/16] KVM: SVM: Add KVM_SEND_UPDATE_DATA command Ashish Kalra
2021-02-04 0:37 ` [PATCH v10 03/16] KVM: SVM: Add KVM_SEV_SEND_FINISH command Ashish Kalra
2021-02-04 0:37 ` [PATCH v10 04/16] KVM: SVM: Add support for KVM_SEV_RECEIVE_START command Ashish Kalra
2021-02-04 0:37 ` [PATCH v10 05/16] KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command Ashish Kalra
2021-02-04 0:37 ` [PATCH v10 06/16] KVM: SVM: Add KVM_SEV_RECEIVE_FINISH command Ashish Kalra
2021-02-04 0:38 ` [PATCH v10 07/16] KVM: x86: Add AMD SEV specific Hypercall3 Ashish Kalra
2021-02-04 0:38 ` [PATCH v10 08/16] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall Ashish Kalra
2021-02-04 16:03 ` Tom Lendacky
2021-02-05 1:44 ` Steve Rutherford
2021-02-05 3:32 ` Ashish Kalra
2021-02-04 0:39 ` [PATCH v10 09/16] mm: x86: Invoke hypercall when page encryption status is changed Ashish Kalra
2021-02-04 0:39 ` [PATCH v10 10/16] KVM: x86: Introduce KVM_GET_SHARED_PAGES_LIST ioctl Ashish Kalra
2021-02-04 16:14 ` Tom Lendacky
2021-02-04 16:34 ` Ashish Kalra
2021-02-17 1:03 ` Sean Christopherson
2021-02-17 14:00 ` Kalra, Ashish
2021-02-17 16:13 ` Sean Christopherson
2021-02-18 6:48 ` Kalra, Ashish
2021-02-18 16:39 ` Sean Christopherson
2021-02-18 17:05 ` Kalra, Ashish
2021-02-18 17:50 ` Sean Christopherson
2021-02-18 18:32 ` Kalra, Ashish
2021-02-24 17:51 ` Ashish Kalra
2021-02-24 18:22 ` Sean Christopherson
2021-02-25 20:20 ` Ashish Kalra
2021-02-25 22:59 ` Steve Rutherford
2021-02-25 23:24 ` Steve Rutherford
2021-02-26 14:04 ` Ashish Kalra
2021-02-26 17:44 ` Sean Christopherson [this message]
2021-03-02 14:55 ` Ashish Kalra
2021-03-02 15:15 ` Ashish Kalra
2021-03-03 18:54 ` Will Deacon
2021-03-03 19:32 ` Ashish Kalra
2021-03-09 19:10 ` Ashish Kalra
2021-03-11 18:14 ` Ashish Kalra
2021-03-11 20:48 ` Steve Rutherford
2021-03-19 17:59 ` Ashish Kalra
2021-04-02 1:40 ` Steve Rutherford
2021-04-02 11:09 ` Ashish Kalra
2021-03-08 10:40 ` Ashish Kalra
2021-03-08 19:51 ` Sean Christopherson
2021-03-08 21:05 ` Ashish Kalra
2021-03-08 21:11 ` Brijesh Singh
2021-03-08 21:32 ` Ashish Kalra
2021-03-08 21:51 ` Steve Rutherford
2021-03-09 19:42 ` Sean Christopherson
2021-03-10 3:42 ` Kalra, Ashish
2021-03-10 3:47 ` Steve Rutherford
2021-03-08 21:48 ` Steve Rutherford
2021-02-17 1:06 ` Sean Christopherson
2021-02-04 0:39 ` [PATCH v10 11/16] KVM: x86: Introduce KVM_SET_SHARED_PAGES_LIST ioctl Ashish Kalra
2021-02-04 0:39 ` [PATCH v10 12/16] KVM: x86: Introduce new KVM_FEATURE_SEV_LIVE_MIGRATION feature & Custom MSR Ashish Kalra
2021-02-05 0:56 ` Steve Rutherford
2021-02-05 3:07 ` Ashish Kalra
2021-02-06 2:54 ` Steve Rutherford
2021-02-06 4:49 ` Ashish Kalra
2021-02-06 5:46 ` Ashish Kalra
2021-02-06 13:56 ` Ashish Kalra
2021-02-08 0:28 ` Ashish Kalra
2021-02-08 22:50 ` Steve Rutherford
2021-02-10 20:36 ` Ashish Kalra
2021-02-10 22:01 ` Steve Rutherford
2021-02-10 22:05 ` Steve Rutherford
2021-02-16 23:20 ` Sean Christopherson
2021-02-04 0:40 ` [PATCH v10 13/16] EFI: Introduce the new AMD Memory Encryption GUID Ashish Kalra
2021-02-04 0:40 ` [PATCH v10 14/16] KVM: x86: Add guest support for detecting and enabling SEV Live Migration feature Ashish Kalra
2021-02-18 17:56 ` Sean Christopherson
2021-02-04 0:40 ` [PATCH v10 15/16] KVM: x86: Add kexec support for SEV Live Migration Ashish Kalra
2021-02-04 0:40 ` [PATCH v10 16/16] KVM: SVM: Bypass DBG_DECRYPT API calls for unencrypted guest memory Ashish Kalra
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=YDkzibkC7tAYbfFQ@google.com \
--to=seanjc@google.com \
--cc=Thomas.Lendacky@amd.com \
--cc=ashish.kalra@amd.com \
--cc=brijesh.singh@amd.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qperret@google.com \
--cc=srutherford@google.com \
--cc=venu.busireddy@oracle.com \
--cc=will@kernel.org \
/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).