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: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 4/4] s390x/kvm: hw debugging support via guest PER facility
Date: Fri, 30 May 2014 11:01:13 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0


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.


Alex




reply via email to

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