Liu Yu-B13201 wrote: > > > >> -----Original Message----- >> From: kvm-ppc-owner@xxxxxxxxxxxxxxx >> [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] On Behalf Of Alexander Graf >> Sent: Wednesday, February 03, 2010 4:57 PM >> To: Liu Yu-B13201 >> Cc: hollis@xxxxxxxxxxxxxx; kvm-ppc@xxxxxxxxxxxxxxx; >> kvm@xxxxxxxxxxxxxxx; Liu Yu-B13201 >> Subject: Re: [PATCH 1/4] kvmppc: guest debug definitions >> >> >> Am 03.02.2010 um 08:53 schrieb Liu Yu <yu.liu@xxxxxxxxxxxxx>: >> >> >>> Signed-off-by: Liu Yu <yu.liu@xxxxxxxxxxxxx> >>> --- >>> 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 <linux/types.h> >>> >>> +/* Select powerpc specific features in <linux/kvm.h> */ >>> +#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 <lv1_get_logical_ppe_id>: 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
