Re: List of unaccessible x86 states

[Gleb Natapov <gleb@redhat.com>]

On Tue, Oct 20, 2009 at 03:51:02PM +0200, Alexander Graf wrote:
> 
> On 20.10.2009, at 15:48, Gleb Natapov wrote:
> 
> >On Tue, Oct 20, 2009 at 03:41:57PM +0200, Alexander Graf wrote:
> >>
> >>On 20.10.2009, at 15:37, Jan Kiszka wrote:
> >>
> >>>Alexander Graf wrote:
> >>>>On 20.10.2009, at 15:01, Jan Kiszka wrote:
> >>>>
> >>>>>Hi all,
> >>>>>
> >>>>>as the list of yet user-unaccessible x86 states is a bit
> >>>>>volatile ATM,
> >>>>>this is an attempt to collect the precise requirements for
> >>>>>additional
> >>>>>state fields. Once everyone feels the list is complete, we can
> >>>>>decide
> >>>>>how to partition it into one ore more substates for the new
> >>>>>KVM_GET/SET_VCPU_STATE interface.
> >>>>>
> >>>>>What I read so far (or tried to patch already):
> >>>>>
> >>>>>- nmi_masked
> >>>>>- nmi_pending
> >>>>>- nmi_injected
> >>>>>- kvm_queued_exception (whole struct content)
> >>>>>- KVM_REQ_TRIPLE_FAULT (from vcpu.requests)
> >>>>>
> >>>>>Unclear points (for me) from the last discussion:
> >>>>>
> >>>>>- sipi_vector
> >>>>>- MCE (covered via kvm_queued_exception, or does it require more?)
> >>>>>
> >>>>>Please extend or correct the list as required.
> >>>>
> >>>>hflags. Qemu supports GIF, kvm supports GIF, but no side
> >>>>knows how to
> >>>>sync it.
> >>>
> >>>BTW, GIF is related to svm nesting, right?
> >>
> >>Yes and no. It's an architecture addition that came with SVM, yes.
> >>
> >>The problem is that I don't want to support migrating while in a
> >Why not?
> 
> Because then we'd have to transfer the whole host cpu cache and the
> merged intercept bitmaps to userspace as well. That's just too many
> internals to expose IMHO.
> 
But the amount of information is constant no matter how l2 guest there
are. Correct? We can expose it as separate substate.

> >>nested VM. We can just #VMEXIT just before migrating with a
> >>VMEXIT_INTR intercept.
> >>
> >We don't notify kernel about migration currently. CPU state is
> >migrated
> >when VM is already paused, how we can exit nested guest at this point?
> 
> Hm - introduce a new ioctl? I haven't fully thought it through yet :-).
> 
There is not software problem that can't be solved by introducing new
ioctl :)

--
			Gleb.