Messages in this thread | | | From | "Kalra, Ashish" <> | Subject | RE: [PATCH v10 10/16] KVM: x86: Introduce KVM_GET_SHARED_PAGES_LIST ioctl | Date | Wed, 17 Feb 2021 14:00:44 +0000 |
| |
[AMD Public Use]
-----Original Message----- From: Sean Christopherson <seanjc@google.com> Sent: Tuesday, February 16, 2021 7:03 PM To: Kalra, Ashish <Ashish.Kalra@amd.com> Cc: pbonzini@redhat.com; tglx@linutronix.de; mingo@redhat.com; hpa@zytor.com; rkrcmar@redhat.com; joro@8bytes.org; bp@suse.de; Lendacky, Thomas <Thomas.Lendacky@amd.com>; x86@kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org; srutherford@google.com; venu.busireddy@oracle.com; Singh, Brijesh <brijesh.singh@amd.com> Subject: Re: [PATCH v10 10/16] KVM: x86: Introduce KVM_GET_SHARED_PAGES_LIST ioctl
On Thu, Feb 04, 2021, Ashish Kalra wrote: > From: Brijesh Singh <brijesh.singh@amd.com> > > The ioctl is used to retrieve a guest's shared pages list.
>What's the performance hit to boot time if KVM_HC_PAGE_ENC_STATUS is passed through to userspace? That way, userspace could manage the set of pages >in whatever data structure they want, and these get/set ioctls go away.
What is the advantage of passing KVM_HC_PAGE_ENC_STATUS through to user-space ?
As such it is just a simple interface to get the shared page list via the get/set ioctl's. simply an array is passed to these ioctl to get/set the shared pages list.
>Also, aren't there plans for an in-guest migration helper? If so, do we have any idea what that interface will look like? E.g. if we're going to end up with a full >fledged driver in the guest, why not bite the bullet now and bypass KVM entirely?
Even the in-guest migration helper will be using page encryption status hypercalls, so some interface is surely required.
Also the in-guest migration will be mainly an OVMF component, won't really be a full fledged kernel driver in the guest.
Thanks, Ashish
| |