qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/4] s390x/kvm: hw debugging support via guest P


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH 4/4] s390x/kvm: hw debugging support via guest PER facility
Date: Fri, 30 May 2014 11:12:23 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 30/05/14 11:01, Alexander Graf wrote:
> 
> On 30.05.14 10:57, Christian Borntraeger wrote:
>> On 30/05/14 10:32, Alexander Graf wrote:
>>
>>>> +    case KVM_HW_BP:
>>>> +        if (find_hw_breakpoint(arch_info->addr, -1, arch_info->type)) {
>>>> +            ret = EXCP_DEBUG;
>>>> +        }
>>>> +        break;
>>>> +    case KVM_SINGLESTEP:
>>>> +        if (cs->singlestep_enabled) {
>>>> +            ret = EXCP_DEBUG;
>>>> +        }
>>>> +        break;
>>>> +    default:
>>>> +        ret = -ENOSYS;
>>>> +    }
>>>> +
>>>> +    return ret;
>>> What happens to the diag 501 now? Are we safe to just drop it?
>> There can only be a small number of HW breakpoints (basically only one 
>> from-to range on s390).
>> So gdb can (and will) use both (hbreak vs. break)
> 
> Ah, let me explain what I'm referring to here. On x86 (and PPC, though the 
> patches are still missing), we use a generic "breakpoint" instruction for sw 
> breakpoints. The specific breakpoint interrupt generated by that instruction 
> traps into KVM which forwards it to QEMU.
> 
> If QEMU now detects that it didn't put the breakpoint into place, it assumes 
> that it's the guest that wanted the breakpoint to happen, so it deflects a 
> breakpoint interrupt into the guest.
> 
> My question here is whether we need something similar on s390x. With DIAG, I 
> think we're safe, as the guest can't expect that one to do anything useful, 
> but if we want to switch to a 2-byte breakpoint instruction instead, it might 
> make sense to implement the deflection mechanism.

Oh, I though "What happens to the diag 501 now? Are we safe to just drop it?" 
was a question if we can get rid of the code.
Regarding deflection, yes if guest and host hardware breakpoints (PER) we need 
to handle that (The host kernel is doing that in filter_guest_per_event)
With software breakpoints: yes diag501 is safe to use. When we change the 
instruction later on then we have to see if we need deflection (could be).

Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]