On 23.10.2009, at 21:34, Jan Kiszka wrote:
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.
Here is a wrap-up of what has been reported so far:
- NMI
o nmi_masked
o nmi_pending
o nmi_injected
- queued exception
o kvm_queued_exception
o triple_fault
- SVM
o gif
(Are we sure that there is really nothing more here?)
Hm, thinking about this again, it might be useful to have an
"currently in nested VM" flag here. That way userspace can decide if
it needs to get out of the nested state (for migration) or if it just
doesn't care.
- sipi_vector
So the next question is how to map these on substates. I'm currently
leaning towards this organization:
- KVM_X86_VCPU_STATE_EVENTS
o NMI states
o pending exception
o sipi_vector
o pending interrupt?
(would be redundant to kvm_sregs.interrupt_bitmap, but that
struct
may be obsoleted one day)
- KVM_X86_VCPU_STATE_SVM
o gif
Can we make this an "svm_flags" or so u32? And then we'd just set bits?
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
