From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH 1/4] kvmppc: guest debug definitions Date: Wed, 03 Feb 2010 10:51:15 +0100 Message-ID: <4B694713.1090109@suse.de> References: <1265183633-2230-1-git-send-email-yu.liu@freescale.com> <1265183633-2230-2-git-send-email-yu.liu@freescale.com> <0A1FE637C2C7E148B9573BB60CC630E5762ADB@zch01exm26.fsl.freescale.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hollis@penguinppc.org, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Liu Yu-B13201 Return-path: Received: from cantor.suse.de ([195.135.220.2]:54421 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755930Ab0BCJvR (ORCPT ); Wed, 3 Feb 2010 04:51:17 -0500 In-Reply-To: <0A1FE637C2C7E148B9573BB60CC630E5762ADB@zch01exm26.fsl.freescale.net> Sender: kvm-owner@vger.kernel.org List-ID: Liu Yu-B13201 wrote: > > > >> -----Original Message----- >> From: kvm-ppc-owner@vger.kernel.org >> [mailto:kvm-ppc-owner@vger.kernel.org] On Behalf Of Alexander Graf >> Sent: Wednesday, February 03, 2010 4:57 PM >> To: Liu Yu-B13201 >> Cc: hollis@penguinppc.org; kvm-ppc@vger.kernel.org; >> kvm@vger.kernel.org; Liu Yu-B13201 >> Subject: Re: [PATCH 1/4] kvmppc: guest debug definitions >> >> >> Am 03.02.2010 um 08:53 schrieb Liu Yu : >> >> >>> Signed-off-by: Liu Yu >>> --- >>> arch/powerpc/include/asm/kvm.h | 20 ++++++++++++++++++++ >>> arch/powerpc/include/asm/kvm_host.h | 16 ++++++++++++++++ >>> 2 files changed, 36 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/ >>> asm/kvm.h >>> index 81f3b0b..b7f7861 100644 >>> --- a/arch/powerpc/include/asm/kvm.h >>> +++ b/arch/powerpc/include/asm/kvm.h >>> @@ -22,6 +22,9 @@ >>> >>> #include >>> >>> +/* Select powerpc specific features in */ >>> +#define __KVM_HAVE_GUEST_DEBUG >>> + >>> struct kvm_regs { >>> __u64 pc; >>> __u64 cr; >>> @@ -71,10 +74,27 @@ struct kvm_fpu { >>> }; >>> >>> struct kvm_debug_exit_arch { >>> + __u32 exception; >>> + __u32 pc; >>> + __u32 status; >>> }; >>> >>> +#define KVM_INST_GUESTGDB 0x44000022 >>> >> What instruction is this again? :) Is it something reserved for >> purposes like this? >> >> > > Just an invalid instruction which can generate program interrupt... > I'm open to it's value btw. > Well this definitely doesn't generate a program interrupt. Or at least it shouldn't :-). I just remembered where I've seen an opcode like this before. This is a part of a dump of arch/powerpc/boot/ps3-hvcall.o 00000000 : 0: 7c 08 02 a6 mflr r0 4: 90 01 00 04 stw r0,4(r1) 8: 94 21 ff f0 stwu r1,-16(r1) c: 90 61 00 08 stw r3,8(r1) 10: 39 60 00 45 li r11,69 14: 44 00 00 22 sc 1 So as you can see, this is the hypercall instruction for lv1. IIRC beat uses the same. I don't think we want to reuse that opcode for ourselves. Maybe one day someone figures it's a good idea to implement a beat-style ABI in KVM. But IIRC sc can take a lot of values, so we can just take sc 0x1234 or so :-). >>> + >>> +#define KVM_GUESTDBG_USE_SW_BP 0x00010000 >>> +#define KVM_GUESTDBG_USE_HW_BP 0x00020000 >>> + >>> +#define KVMPPC_DEBUG_NOTYPE 0x0 >>> +#define KVMPPC_DEBUG_BREAKPOINT (1UL << 1) >>> +#define KVMPPC_DEBUG_WATCH_WRITE (1UL << 2) >>> +#define KVMPPC_DEBUG_WATCH_READ (1UL << 3) >>> + >>> /* for KVM_SET_GUEST_DEBUG */ >>> struct kvm_guest_debug_arch { >>> + struct { >>> + __u32 addr; >>> + __u32 type; >>> + } bp[6]; >>> >> I can't look up the sources right now. Is this a struct that >> 1:1 maps >> to an ioctl struct? If so, we should add padding for a >> possible future >> extension of debug registers. >> > > Yes it's used by ioctl. > What's the usually pad size? > I don't think there's a default. I just tend to pad it to something reasonable. I guess in this case we can even just extend bp to 128 entries, add a reasonable amount of churn to the debug info and be good: struct kvm_guest_debug_arch { struct { __u64 addr; __u32 type; __u32 pad1; __u64 pad2; } bp[128]; } This should be enough to even leverage performance monitoring stuff later on that would be able to check if r1 == 0x1234 and then stop :-). Alex