From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 7/8] kvm: nVMX: Introduce KVM_CAP_VMX_STATE Date: Mon, 8 Jan 2018 19:11:58 +0100 Message-ID: References: <1480536229-11754-1-git-send-email-jmattson@google.com> <7d9c263c-3d21-8535-5fed-35adfdfb71be@redhat.com> <89880fbd-2d47-d994-81f5-2073eec96ce0@redhat.com> <3bbb7742-ece1-0e8a-cc73-45d5160bc6c4@redhat.com> <75bde61a-34ff-c0af-436e-c8328fe7e870@redhat.com> <67833a23-5dd4-c502-d724-fea5598c41df@redhat.com> <2301ab3e-c318-4494-4c1e-bd85e24ef78c@redhat.com> <4c348439-81f7-11e9-0e68-3e18df86f4c4@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: kvm list , David Hildenbrand To: David Hildenbrand , Jim Mattson Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58254 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754855AbeAHSMA (ORCPT ); Mon, 8 Jan 2018 13:12:00 -0500 In-Reply-To: Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: On 08/01/2018 18:59, David Hildenbrand wrote: > On 08.01.2018 18:36, Paolo Bonzini wrote: >> On 08/01/2018 11:35, David Hildenbrand wrote: >>> Thinking about it, I agree. It might be simpler/cleaner to transfer the >>> "loaded" VMCS. But I think we should take care of only transferring data >>> that actually is CPU state and not special to our current >>> implementation. (e.g. nested_run_pending I would says is special to out >>> current implementation, but we can discuss) >>> >>> So what I would consider VMX state: >>> - vmxon >>> - vmxon_ptr >>> - vmptr >>> - cached_vmcs12 >>> - ... ? >> >> nested_run_pending is in the same boat as the various >> KVM_GET_VCPU_EVENTS flags (e.g. nmi.injected vs. nmi.pending). It's not >> "architectural" state, but it's part of the state machine so it has to >> be serialized. > > I am wondering if we can get rid of it. In fact if we can go out of VMX > mode every time we go to user space. There are cases where this is not possible, for example if you have a nested "assigned device" that is emulated by userspace. Paolo > As soon as we put it into the > official VMX migration protocol, we have to support it. Now seems like > the last time we can change it. > > I have the following things in mind (unfortunately I don't have time to > look into the details) to make nested_run_pending completely internal state. > > 1. When going into user space, if we have nested_run_pending=true, set > it to false and rewind the PSW to point again at the VMLAUNCH/VMRESUME > function. The next VCPU run will simply continue executing the nested > guest (trying to execute the VMLAUNCH/VMRESUME again). > > 2. When going into user space, if we have nested_run_pending=true, set > it to false and fake another VMX exit that has no side effects (if > possible). Something like the NULL intercept we have on s390x. > > But I have no idea how that plays e.g. with KVM_GET_VCPU_EVENTS (again, > unfortunately no time to look into all the details). If we could get 1. > running it would be cool, but I am not sure if it is feasible. > > If not, than we most likely will have to stick to it :( And as Paolo > said, migrate it. > > Thanks > >> >> Thanks, >> >> Paolo >> > >