On 02/14/2010 12:34 PM, Gleb Natapov wrote:
event_exit_inst_len is only used for event reinjection. Since event
intercepted here will not be reinjected why updating event_exit_inst_len
is needed here?
In guest debugging mode a #BP exception is always reported to user space
to find out what caused it. If it was the guest itself, the exception is
reinjected, on older kernels via KVM_SET_GUEST_DEBUG and since 2.6.33
via KVM_SET_VCPU_EVENTS (the latter requires some qemu patch that I will
post later).
As we currently do not update event_exit_inst_len on #BP exits,
reinjecting fails unless event_exit_inst_len happens to be 1 from some
other exit.
Hmm, how does it work on SVM then where we do not have
event_exit_inst_len so execution will resume on the same rip that caused
#BP after event reinjection?
Note, newer AMDs do have such a field (nRIP, 0xC8). We need to support
older machines, though.
--
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
