Avi Kivity wrote: > 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
For sure, just needs a tiny cleanup in svm.c that I had in some other patches. > >> + vmx_inject_irq(vcpu, vec); >> > > kvm_queue_exception() OK. > >> + return 1; >> + } >> return 0; >> } >> > > But it seems the best thing to do is not to trap #DB in > update_exception_bitmap()? Was my first idea as well. I do not understand what is going on there, but when I simply exclude #DB from the exception bitmap in real mode, the problem pops up again: #GP on the instruction that should raise the #DB. > >> /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. Hmm, unless KVM did something to fix up some exception, shouldn't all of them be passed? Jan
signature.asc
Description: OpenPGP digital signature