On Sun, Jul 13, 2008 at 12:09 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> 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.
>
I did send out this patch yesterday, modifying this very bit. I added
a #define for DB_VECTOR in kvm_host.h
>>
>>> + vmx_inject_irq(vcpu, vec);
>>>
>>
>> kvm_queue_exception()
>
> OK.
Not so fast, the GP# pops up again with kvm_queue_exception(). Why
should we use kvm_queue_exception() here? Shouldn't this be the part
where we handle/service that exception, rather than adding it, may be
I am misunderstanding so CIIW.
>
>>
>>> + 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.
>
Does this happen with your guest-debugging patchset. I tried the same
thing with the vanilla kvm and got a breakpoint instead.
>>
>>> /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
>
>
--
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
