On 04.10.2012, at 09:14, Bhushan Bharat-R65777 wrote:

> 
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Monday, September 24, 2012 9:09 PM
>> To: Bhushan Bharat-R65777
>> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Bhushan Bharat-R65777
>> Subject: Re: [PATCH 4/6] KVM: PPC: debug stub interface parameter defined
>> 
>> 
>> On 21.08.2012, at 15:51, Bharat Bhushan wrote:
>> 
>>> This patch defines the interface parameter for KVM_SET_GUEST_DEBUG
>>> ioctl support. Follow up patches will use this for setting up hardware
>>> breakpoints, watchpoints and software breakpoints.
>>> 
>>> Signed-off-by: Bharat Bhushan <bharat.bhus...@freescale.com>
>>> ---
>>> arch/powerpc/include/asm/kvm.h |   33 +++++++++++++++++++++++++++++++++
>>> arch/powerpc/kvm/book3s.c      |    6 ++++++
>>> arch/powerpc/kvm/booke.c       |    6 ++++++
>>> arch/powerpc/kvm/powerpc.c     |    6 ------
>>> 4 files changed, 45 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/arch/powerpc/include/asm/kvm.h
>>> b/arch/powerpc/include/asm/kvm.h index 3c14202..61b197e 100644
>>> --- a/arch/powerpc/include/asm/kvm.h
>>> +++ b/arch/powerpc/include/asm/kvm.h
>>> @@ -269,8 +269,41 @@ struct kvm_debug_exit_arch {
>>> 
>>> /* for KVM_SET_GUEST_DEBUG */
>>> struct kvm_guest_debug_arch {
>>> +   struct {
>>> +           /* H/W breakpoint/watchpoint address */
>>> +           __u64 addr;
>>> +           /*
>>> +            * Type denotes h/w breakpoint, read watchpoint, write
>>> +            * watchpoint or watchpoint (both read and write).
>>> +            */
>>> +#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)
>>> +           __u32 type;
>>> +           __u32 pad1;
>> 
>> Why the padding?
> 
> Not sure why, I will remove this.

Oh, I think the padding makes sense - depending on the type of interrupt this 
could for example mean "break when write to address x becomes value y".

I'm not sure the amount of padding and the structure of it is the right way to 
go though: We probably want to have a union here defining type specific 
payloads.

> 
>> 
>>> +           __u64 pad2;
>>> +   } bp[16];
>> 
>> Why 16?
> 
> I think for now 6 (4 iac + 2 dac) is sufficient for BOOKE. We kept 16 to have 
> some room for future and other platforms.

Ok :)


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to