On 10.08.2012, at 08:55, Bhushan Bharat-R65777 wrote: > > >> -----Original Message----- >> From: kvm-ppc-owner@xxxxxxxxxxxxxxx [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] On >> Behalf Of Alexander Graf >> Sent: Wednesday, August 08, 2012 4:41 PM >> To: Bhushan Bharat-R65777 >> Cc: Wood Scott-B07421; kvm-ppc@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx >> Subject: Re: [PATCH 3/3] KVM: PPC: booke: Added debug handler >> >> >> On 08.08.2012, at 03:02, Bhushan Bharat-R65777 wrote: >> >>> >>> >>>> -----Original Message----- >>>> From: Wood Scott-B07421 >>>> Sent: Wednesday, August 08, 2012 2:15 AM >>>> To: Alexander Graf >>>> Cc: Bhushan Bharat-R65777; kvm-ppc@xxxxxxxxxxxxxxx; >>>> kvm@xxxxxxxxxxxxxxx; Bhushan >>>> Bharat-R65777 >>>> Subject: Re: [PATCH 3/3] KVM: PPC: booke: Added debug handler >>>> >>>> On 08/07/2012 05:47 AM, Alexander Graf wrote: >>>>>> diff --git a/arch/powerpc/kvm/booke_interrupts.S >>>>>> b/arch/powerpc/kvm/booke_interrupts.S >>>>>> index 3539805..890673c 100644 >>>>>> --- a/arch/powerpc/kvm/booke_interrupts.S >>>>>> +++ b/arch/powerpc/kvm/booke_interrupts.S >>>>>> @@ -73,6 +73,51 @@ _GLOBAL(kvmppc_handler_\ivor_nr) >>>>>> bctr >>>>>> .endm >>>>>> >>>>>> +.macro KVM_DBG_HANDLER ivor_nr scratch srr0 >>>>> >>>>> This is a lot of asm code. Any chance to share a good share of it >>>>> with the >>>> generic handler? >>>> >>>> That entire file could use an update to lok more like >>>> bookehv_interrupts.S and its use of asm macros. >>> >>> In booke there is assumption that size of KVM IVORs will not me more than host >> IVORs size so that only IVPR is changed. >>> >>> I tried to give it that shape of bookehv_interrupts.S and found that size of >> some IVORs become more than host IVORs. >> >> We can always jump off to another (more generic?) function and only have a small >> stub in the IVOR referenced code. > > What extra KVM_DBG_HANDLER have from KVM_HANDLER is the handing of debug single step (which is similar to host). > So do you want a jump in assembly for handling the debug single step? Or you really think of moving something from the KVM_HANDLER to more generic? I'm thinking of "if we don't have enough space in block A, create another block B that has more space to handle things again" :). I'll leave the implementation details to you :D Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html