Re: [PATCH v2 03/10] KVM: arm: guest debug, define API headers

[Alex BennÃe]

Christoffer Dall <christoffer.dall@xxxxxxxxxx> writes:

> On Tue, Mar 31, 2015 at 04:08:01PM +0100, Alex BennÃe wrote:
>> This commit defines the API headers for guest debugging. There are two
>> architecture specific debug structures:
>> 
>>   - kvm_guest_debug_arch, allows us to pass in HW debug registers
>>   - kvm_debug_exit_arch, signals the exact debug exit and pc
>> 
>> The type of debugging being used is control by the architecture specific
>> control bits of the kvm_guest_debug->control flags in the ioctl
>> structure.
>> 
>> Signed-off-by: Alex BennÃe <alex.bennee@xxxxxxxxxx>
>> 
>> ---
>> v2
>>    - expose hsr and pc directly to user-space
>> 
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 3ef77a4..6ee70a0 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -100,10 +100,24 @@ struct kvm_sregs {
>>  struct kvm_fpu {
>>  };
>>  
>> +/*
>> + * See ARM ARM D7.3: Debug Registers
>
> see the ARM ARM for ??
>
>> + *
>> + * The control registers are architecturally defined as 32 bits but are
>> + * stored as 64 bit values along side the value registers and aligned
>
> do you mean alongside?

sure.

>
>> + * with the rest 64 bit registers in the normal CPU context.
>
> rest of the 64 bit
>
>> + */
>
> why do we store them as 64 bit values?  There's nothing prevented us
> from defining them as __u32 is there?  Is this to make the ONE_REG
> interface accessers more convenient?

No but it will involve more fiddling when we copy them into the CPU
context which keeps everything as 64 bit aligned. Of course if we want
to remove the debug registers from the context and put a pointer in
place then this is fairly moot as we will need to change the hyp.S code
that copies the registers during the world switch. I was trying to
minimise the amount of change to the assembler in this series.

>
>> +#define KVM_ARM_NDBG_REGS 16
>
> nit: is NDBG short for something I don't know about or is it
> the number of debug registers we are noting here, in which case I think
> KVM_ARM_NUM_DBG_REGS is more clear.

OK.

>
>>  struct kvm_guest_debug_arch {
>> +	__u64 dbg_bcr[KVM_ARM_NDBG_REGS];
>> +	__u64 dbg_bvr[KVM_ARM_NDBG_REGS];
>> +	__u64 dbg_wcr[KVM_ARM_NDBG_REGS];
>> +	__u64 dbg_wvr[KVM_ARM_NDBG_REGS];
>>  };
>>  
>>  struct kvm_debug_exit_arch {
>> +	__u64 pc;
>> +	__u32 hsr;
>>  };
>>  
>>  struct kvm_sync_regs {
>> @@ -207,4 +221,11 @@ struct kvm_arch_memory_slot {
>>  
>>  #endif
>>  
>> +/*
>> + * Architecture related debug defines - upper 16 bits of
>> + * kvm_guest_debug->control
>> + */
>> +#define KVM_GUESTDBG_USE_SW_BP	        __KVM_GUESTDBG_USE_SW_BP
>> +#define KVM_GUESTDBG_USE_HW_BP		__KVM_GUESTDBG_USE_HW_BP
>> +
>>  #endif /* __ARM_KVM_H__ */
>> -- 
>> 2.3.4
>> 
>
> Thanks,
> -Christoffer

-- 
Alex BennÃe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/