> -----Original Message----- > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf > Of > Alexander Graf > Sent: Friday, May 03, 2013 6:48 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 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()?
No, On e500v2, we uses DBCR1 and DBCR2 to not allow debug events when MSR.PR = 0 On e500mc+, we uses EPCR.DUVD to not allow debug events when in hypervisor mode. -Bharat > > > 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 -- 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
