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_VECTORFor 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
