From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [QEMU PATCH v2 0/2]: KVM: i386: Add support for save and restore nested state Date: Thu, 8 Nov 2018 18:02:58 +0100 Message-ID: References: <20181102034649.43559-1-liran.alon@oracle.com> <1C803EF0-9E1B-4E1B-A4DD-4BE788A7A1FF@oracle.com> <939A6255-306C-431C-8799-0D56A30A3BD5@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Eduardo Habkost , kvm list , mtosatti@redhat.com, "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Jim Mattson , rth@twiddle.net To: Liran Alon Return-path: In-Reply-To: <939A6255-306C-431C-8799-0D56A30A3BD5@oracle.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel2=m.gmane.org@nongnu.org Sender: "Qemu-devel" List-Id: kvm.vger.kernel.org On 08/11/2018 10:57, Liran Alon wrote: >=20 >=20 >> On 8 Nov 2018, at 11:50, Paolo Bonzini wrote: >> >> On 08/11/2018 01:45, Jim Mattson wrote: >>> I have no attachments to the current design. I had used a data[] blob= , >>> because I didn't think userspace would have any need to know what was >>> in there. However, I am now seeing the error of my ways. For example, >>> the userspace instruction emulator needs to know the contents of the >>> vmcs12 to emulate instructions when in guest mode. >> >> Yeah, we're probably going to have to document the KVM vmcs12 structur= e, >> possibly moving it to uapi. But that's a different thing from >> save/restore state, which can use the 4K or 8K data[] blob. >> >> Paolo >=20 > But regardless of if we document vmcs12 or not, the current blob we > have today should be separated to well-defined blobs/structs (cached_vm= cs12 > and cached_shadow_vmcs12) and each blob should have a relevant flag tha= t specifies > it is valid (saved by kernel or requested to be restored by userspace). > Additional future nested-state should be added as additional > well-defined blobs/structs with appropriate flags. We are somewhat limited by the ABI of the released kernel versions, and it's unlikely that the structure will change in the short term. So I think it's okay if we just define that the first 4K of data are the VMCS and the second 8K are the shadow VMCS, whenever format=3D0 in the kvm_nested_state struct. Paolo > Then, in QEMU, each such well-defined blob/struct should have it=E2=80=99= s own subsection with a relevant .needed() method. > This will allow us to preserve required backwards compatibility. >=20 > Agreed? >=20 > -Liran >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKni5-0002ol-Sc for qemu-devel@nongnu.org; Thu, 08 Nov 2018 12:03:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gKni3-0007wk-3r for qemu-devel@nongnu.org; Thu, 08 Nov 2018 12:03:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54634) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gKni2-0007li-Qv for qemu-devel@nongnu.org; Thu, 08 Nov 2018 12:03:11 -0500 References: <20181102034649.43559-1-liran.alon@oracle.com> <1C803EF0-9E1B-4E1B-A4DD-4BE788A7A1FF@oracle.com> <939A6255-306C-431C-8799-0D56A30A3BD5@oracle.com> From: Paolo Bonzini Message-ID: Date: Thu, 8 Nov 2018 18:02:58 +0100 MIME-Version: 1.0 In-Reply-To: <939A6255-306C-431C-8799-0D56A30A3BD5@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [QEMU PATCH v2 0/2]: KVM: i386: Add support for save and restore nested state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liran Alon Cc: Jim Mattson , "Dr. David Alan Gilbert" , Eduardo Habkost , kvm list , mtosatti@redhat.com, rth@twiddle.net, qemu-devel@nongnu.org On 08/11/2018 10:57, Liran Alon wrote: >=20 >=20 >> On 8 Nov 2018, at 11:50, Paolo Bonzini wrote: >> >> On 08/11/2018 01:45, Jim Mattson wrote: >>> I have no attachments to the current design. I had used a data[] blob= , >>> because I didn't think userspace would have any need to know what was >>> in there. However, I am now seeing the error of my ways. For example, >>> the userspace instruction emulator needs to know the contents of the >>> vmcs12 to emulate instructions when in guest mode. >> >> Yeah, we're probably going to have to document the KVM vmcs12 structur= e, >> possibly moving it to uapi. But that's a different thing from >> save/restore state, which can use the 4K or 8K data[] blob. >> >> Paolo >=20 > But regardless of if we document vmcs12 or not, the current blob we > have today should be separated to well-defined blobs/structs (cached_vm= cs12 > and cached_shadow_vmcs12) and each blob should have a relevant flag tha= t specifies > it is valid (saved by kernel or requested to be restored by userspace). > Additional future nested-state should be added as additional > well-defined blobs/structs with appropriate flags. We are somewhat limited by the ABI of the released kernel versions, and it's unlikely that the structure will change in the short term. So I think it's okay if we just define that the first 4K of data are the VMCS and the second 8K are the shadow VMCS, whenever format=3D0 in the kvm_nested_state struct. Paolo > Then, in QEMU, each such well-defined blob/struct should have it=E2=80=99= s own subsection with a relevant .needed() method. > This will allow us to preserve required backwards compatibility. >=20 > Agreed? >=20 > -Liran >=20