On 03.05.2013, at 15:11, Bhushan Bharat-R65777 wrote: > > >> -----Original Message----- >> From: Alexander Graf [mailto:ag...@suse.de] >> Sent: Friday, May 03, 2013 6:00 PM >> To: Bhushan Bharat-R65777 >> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421 >> Subject: Re: [PATCH 7/7 v3] KVM: PPC: Add userspace debug stub support >> >> >> On 03.05.2013, at 13:08, Alexander Graf wrote: >> >>> >>> >>> Am 03.05.2013 um 12:48 schrieb Bhushan Bharat-R65777 <r65...@freescale.com>: >>> >>>>>>>> +static void kvmppc_booke_vcpu_load_debug_regs(struct kvm_vcpu >>>>>>>> +*vcpu) { >>>>>>>> + if (!vcpu->arch.debug_active) >>>>>>>> + return; >>>>>>>> + >>>>>>>> + /* Disable all debug events and clead pending debug events */ >>>>>>>> + mtspr(SPRN_DBCR0, 0x0); >>>>>>>> + kvmppc_clear_dbsr(); >>>>>>>> + >>>>>>>> + /* >>>>>>>> + * Check whether guest still need debug resource, if not then >>>>>>>> there >>>>>>>> + * is no need to restore guest context. >>>>>>>> + */ >>>>>>>> + if (!vcpu->arch.shadow_dbg_reg.dbcr0) >>>>>>>> + return; >>>>>>>> + >>>>>>>> + /* Load Guest Context */ >>>>>>>> + mtspr(SPRN_DBCR1, vcpu->arch.shadow_dbg_reg.dbcr1); >>>>>>>> + mtspr(SPRN_DBCR2, vcpu->arch.shadow_dbg_reg.dbcr2); #ifdef >>>>>>>> +CONFIG_KVM_E500MC >>>>>>>> + mtspr(SPRN_DBCR4, vcpu->arch.shadow_dbg_reg.dbcr4); >>>>>>> >>>>>>> You need to make sure DBCR4 is 0 when you leave things back to >>>>>>> normal user space. Otherwise guest debug can interfere with host debug. >>>>>> >>>>>> >>>>>> ok >>>>>> >>>>>>> >>>>>>>> +#endif >>>>>>>> + mtspr(SPRN_IAC1, vcpu->arch.shadow_dbg_reg.iac[0]); >>>>>>>> + mtspr(SPRN_IAC2, vcpu->arch.shadow_dbg_reg.iac[1]); >>>>>>>> +#if CONFIG_PPC_ADV_DEBUG_IACS > 2 >>>>>>>> + mtspr(SPRN_IAC3, vcpu->arch.shadow_dbg_reg.iac[2]); >>>>>>>> + mtspr(SPRN_IAC4, vcpu->arch.shadow_dbg_reg.iac[3]); >>>>>>>> +#endif >>>>>>>> + mtspr(SPRN_DAC1, vcpu->arch.shadow_dbg_reg.dac[0]); >>>>>>>> + mtspr(SPRN_DAC2, vcpu->arch.shadow_dbg_reg.dac[1]); >>>>>>>> + >>>>>>>> + /* Enable debug events after other debug registers restored */ >>>>>>>> + mtspr(SPRN_DBCR0, vcpu->arch.shadow_dbg_reg.dbcr0); } >>>>>>> >>>>>>> All of the code above looks suspiciously similar to >>>>>>> prime_debug_regs();. Can't we somehow reuse that? >>>>>> >>>>>> I think we can if >>>>>> - Save thread->debug_regs in local data structure >>>>> >>>>> Yes, it can even be on the stack. >>>>> >>>>>> - Load vcpu->arch->debug_regs in thread->debug_regs >>>>>> - Call prime_debug_regs(); >>>>>> - Restore thread->debug_regs from local save values in first step >>>>> >>>>> On heavyweight exit, based on the values on stack, yes. >>>> >>>> This is how I think we can save/restore debug context. Please correct if I >>>> am >> missing something. >>> >>> Sounds about right :) >> >> Actually, what happens if a guest breakpoint is set to a kernel address that >> happens to be within the scope of kvm code? > > You mean address of kvm code in guest or host? > > If host, we already mentioned that we do not support that. Right?
QEMU wants to debug the guest at address 0xc0000123. kvm_run happens to be at that address. We switch the debug registers through prime_debug_regs. Will the host kernel receive a debug interrupt when it runs kvm_run()? Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
