On 10/04/2009 12:50 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 10/04/2009 10:59 AM, Jan Kiszka wrote:
Hi,
while preparing new IOCTLs to let user space query& set the yet
unaccessible NMI states (pending and masked) I also came across the
interrupt shadow masks. Unless I missed something I would say that we so
far break them in the rare case that a migration happens right while any
of them is asserted. So I guess I should extend my interface and stuff
them in as well.
Do we have more of such unaccessible states on x86 that could be
included, too? Would be a good chance...
There's some hidden state in the cpuid mechanism. I think we expose it
though (just don't use it in qemu).
Do you have more details on this?
Some cpuid leaves return different information based on an internal
counter. This is indicated by KVM_CPUID_FLAG_STATEFUL_FUNC.
The PDPTRs are hidden state that we should save/restore, though no sane
guest relies on them.
A quick glance at SVM makes me think that those registered are not
exposed there. So when keeping in mind that we may only help VMX guests,
I think i makes even less sense to "fix" this, does it?
Yes. With npt the PDPTRs are essentially gone.
I think we can lose information if we migrate during a SIPI
(sipi_vector), though that might be fixable without exposing it.
Hmm, I see. But even it it's not fixable, such an extension would be an
in-kernel irqchip thing.
Yes.
We'll might also lost debug traps.
We drop pending exceptions; normally that's fine since they'll reinject
themselves, but MCE will not.
So would it make sense and fix those two issues when we simply save and
restore the pending exception?
Yes.
btw, instead of adding a new ioctl, perhaps it makes sense to define a
new KVM_VCPU_STATE structure that holds all current and future state
(with generous reserved space), instead of separating state over a dozen
ioctls.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
