Re: List of unaccessible x86 states

[Gleb Natapov <gleb@redhat.com>]

On Tue, Oct 20, 2009 at 08:59:48PM +0200, Alexander Graf wrote:
> 
> On 20.10.2009, at 20:55, Gleb Natapov wrote:
> 
> >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.
> 
> Or we can just not migrate while in a nested guest :-). Which will
> make everything a lot easier.
> 
Suppose we have a l2 guest that handles interrupt/nmis by itself how can we
force it to exit? I don't think requesting certain cpu state before
migration is the right thing to do. What if user paused a VM and then
decided to migrate? Or VM was paused automatically because of shortage
of disk space and management want to migrate VM to other host with
bigger disk?

--
			Gleb.