On 08/16/2012 10:12 AM, Bhushan Bharat-R65777 wrote: > > >> -----Original Message----- >> From: Wood Scott-B07421 >> Sent: Tuesday, July 31, 2012 3:31 AM >> To: Bhushan Bharat-R65777 >> Cc: Wood Scott-B07421; kvm-ppc@vger.kernel.org; k...@vger.kernel.org; >> ag...@suse.de >> Subject: Re: [PATCH 2/2] KVM: PPC: booke/bookehv: Add guest debug support >> >> On 07/30/2012 02:37 AM, Bhushan Bharat-R65777 wrote: >>> >>> >>>> -----Original Message----- >>>> From: Wood Scott-B07421 >>>> Sent: Friday, July 27, 2012 7:00 AM >>>> To: Bhushan Bharat-R65777 >>>> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; ag...@suse.de; >>>> Bhushan Bharat- >>>> R65777 >>>> Subject: Re: [PATCH 2/2] KVM: PPC: booke/bookehv: Add guest debug >>>> support >>>> >>>>> +#ifndef CONFIG_PPC_FSL_BOOK3E >>>>> + PPC_LD(r7, VCPU_HOST_DBG+KVMPPC_DBG_IAC3, r4) >>>>> + PPC_LD(r8, VCPU_HOST_DBG+KVMPPC_DBG_IAC4, r4) >>>>> + mtspr SPRN_IAC3, r7 >>>>> + mtspr SPRN_IAC4, r8 >>>>> +#endif >>>> >>>> Can you handle this at runtime with a feature section? >>> >>> Why you want this to make run time? Removing config_ ? >> >> Currently KVM hardcodes the target hardware in a way that is unacceptable in >> much of the rest of the kernel. We have a long term goal to stop doing that, >> and we should avoid making it worse by adding random ifdefs for specific >> CPUs. > > I do not see any CPU_FTR_* which I can use directly. Should I define a new > FTR, something like: > > #define CPU_FTR_DEBUG_E500 LONG_ASM_CONST(0x4000000000000000) > > Use this in: CPU_FTRS_E500_2, CPU_FTRS_E500MC, CPU_FTRS_E5500 etc > > BEGIN_FTR_SECTION > PPC_LD(r7, VCPU_HOST_DBG+KVMPPC_DBG_IAC3, r4) > PPC_LD(r8, VCPU_HOST_DBG+KVMPPC_DBG_IAC4, r4) > mtspr SPRN_IAC3, r7 > mtspr SPRN_IAC4, r8 > END_FTR_SECTION_IFCLR(CPU_FTR_DEBUG_E500)
It looks like other parts of the kernel use CONFIG_PPC_ADV_DEBUG_IACS for this, though ideally it would be made runtime in the future. -Scott -- 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
