On Wed, Mar 27, 2019 at 1:34 PM Sean Christopherson
<sean.j.christopherson@xxxxxxxxx> wrote:
>
> On Wed, Mar 27, 2019 at 01:28:09PM -0700, Jim Mattson wrote:
> > On Wed, Mar 27, 2019 at 1:20 PM Sean Christopherson
> > <sean.j.christopherson@xxxxxxxxx> wrote:
> > >
> > > On Wed, Mar 27, 2019 at 12:50:27PM -0700, Jim Mattson wrote:
> > > > Where does this state get saved/restored when suspending/resuming a
> > > > VCPU that's in SMM?
> > >
> > > cr4_vmxe is handled by vmx_pre_smi_save_state() and
> > > vmx_post_rsm_load_state().
> > >
> > > The existing vmxon and guest_mode are handled by post_smi_save_state()
> > > and pre_rsm_load_state(), which were previously pre_{enter,leave}_smm().
> > >
> > > Ideally everything in the struct would be managed together, e.g. in
> > > vmx_pre_smi_save_state() and vmx_post_rsm_load_state(), but I didn't
> > > want to touch that house of cards at this time.
> > >
> > > And even more ideally, post_smi_save_state() and pre_rsm_load_state()
> > > would be dropped altogether, e.g. the SVM code would also be reworked to
> > > use pre_smi_save_state() and post_rsm_load_state(), but my SVM knowledge
> > > is nowhere near sufficient to judge if that's even remotely feasible.
> >
> > No; I meant which of the myriad KVM_GET_* and KVM_SET_* ioctls provide
> > a mechanism to save and restore these tidbits of vCPU state (e.g. for
> > live migration)?
>
> Ah fudge. KVM_{GET,SET}_NESTED_STATE, i.e. vmx_{get,set}_nested_state().
> This patch would also need to add and handle KVM_STATE_NESTED_SMM_CR4_VMXE.
Sorry. I haven't been following the evolution of those ioctls since I
first proposed them and Paolo shut me down. I see the handling of
"nested SMM state" now, and I agree that this would be the place to
handle the internal stash of CR4.VMXE. However, vmx_set_nested_state
currently allows only two bits to be set in vmx.smm.flags:
KVM_STATE_NESTED_SMM_GUEST_MODE and KVM_STATE_NESTED_SMM_VMXON. Does
userspace have to opt-in to KVM_STATE_NESTED_SMM_CR4_VMXE through a
new KVM_CAP?
