Jan Kiszka wrote:
It looks like that we should forward all #DB exceptions to the guest in
real mode unless we are sure they were caused by a host-injection. Here
is more or less a hack to achieve this (breaking guest debugging for
now):
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index b60fcec..a6f9c9b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2244,6 +2244,15 @@ static int handle_rmode_exception(struct kvm_vcpu *vcpu,
if (((vec == GP_VECTOR) || (vec == SS_VECTOR)) && err_code == 0)
if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE)
return 1;
+ /*
+ * Forward #DB
+ * FIXME: Quick-hack, breaks guest debugging in real mode, will be
+ * fixed with the required debugging infrastructure rework.
+ */
+ if (vec == 1) {
DB_VECTOR
+ vmx_inject_irq(vcpu, vec);
kvm_queue_exception()
+ return 1;
+ }
return 0;
}
But it seems the best thing to do is not to trap #DB in
update_exception_bitmap()?
/me now wonders if there are not even more exceptions that have to be
forwarded. Right now we catch them all, but I did not find some path
via which actual ones are pushed to the guest.
Looks like update_exception_bitmap() assumes none. From a cursory look,
seems like #DE (divide error), #DB, #BP (Breakpoint), #OF (overflow),
#BR (range check) all need to be passed to the guest.
--
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
