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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to