>________________________________________ >From: Alexander Graf [agraf@xxxxxxx] >Sent: Saturday, July 07, 2012 2:11 AM >To: Caraman Mihai Claudiu-B02008 >Cc: Benjamin Herrenschmidt; <kvm-ppc@xxxxxxxxxxxxxxx>; KVM list; linuxppc-dev; qemu-ppc@xxxxxxxxxx List >Subject: Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks > >On 07.07.2012, at 00:33, Caraman Mihai Claudiu-B02008 wrote: > >>> -----Original Message----- >>> From: Benjamin Herrenschmidt [mailto:benh@xxxxxxxxxxxxxxxxxxx] >>> Sent: Thursday, July 05, 2012 1:26 AM >>> To: Alexander Graf >>> Cc: Caraman Mihai Claudiu-B02008; <kvm-ppc@xxxxxxxxxxxxxxx>; KVM list; >>> linuxppc-dev; qemu-ppc@xxxxxxxxxx List >>> Subject: Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM >>> kernel hooks >>> >>> You can't but in any case I don't see the point of the conditional here, >>> we'll eventually have to load srr1 no ? We can move the load up to here >>> in all cases or can't we ? >> >> I like the idea, but there is a problem with addition macros which may clobber >> r11 and PROLOG_ADDITION_MASKABLE_GEN is such a case. > >Mike -v please :) Ben suggested something like this: #define EXCEPTION_PROLOG(n, type, addition) \ mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ \ mfspr r13,SPRN_SPRG_PACA; /* get PACA */ \ std r10,PACA_EX##type+EX_R10(r13); \ std r11,PACA_EX##type+EX_R11(r13); \ mfcr r10; /* save CR */ \ + mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \ DO_KVM intnum,srr1; \ addition; /* additional code for that exc. */ \ std r1,PACA_EX##type+EX_R1(r13); /* save old r1 in the PACA */ \ stw r10,PACA_EX##type+EX_CR(r13); /* save old CR in the PACA */ \ - mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \ type##_SET_KSTACK; /* get special stack if necessary */\ andi. r10,r11,MSR_PR; /* save stack pointer */ \ But one of the addition looks like this: #define PROLOG_ADDITION_MASKABLE_GEN(n) \ lbz r11,PACASOFTIRQEN(r13); /* are irqs soft-disabled ? */ \ cmpwi cr0,r11,0; /* yes -> go out of line */ \ beq masked_interrupt_book3e_##n So for maskable gen we end up with: #define EXCEPTION_PROLOG(n, type, addition) \ mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ \ mfspr r13,SPRN_SPRG_PACA; /* get PACA */ \ std r10,PACA_EX##type+EX_R10(r13); \ std r11,PACA_EX##type+EX_R11(r13); \ mfcr r10; /* save CR */ \ mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \ DO_KVM intnum,srr1; \ lbz r11,PACASOFTIRQEN(r13); /* are irqs soft-disabled ? */ \ cmpwi cr0,r11,0; /* yes -> go out of line */ \ beq masked_interrupt_book3e_##n \ std r1,PACA_EX##type+EX_R1(r13); /* save old r1 in the PACA */ \ stw r10,PACA_EX##type+EX_CR(r13); /* save old CR in the PACA */ \ type##_SET_KSTACK; /* get special stack if necessary */\ andi. r10,r11,MSR_PR; /* save stack pointer */ \ This affects the last asm line, we load srr1 into r11 but clobber it in-between. We need a spare register for maskable gen addition. I think we can free r10 sooner and used it in addition like this: #define EXCEPTION_PROLOG(n, type, addition) \ mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ \ mfspr r13,SPRN_SPRG_PACA; /* get PACA */ \ std r10,PACA_EX##type+EX_R10(r13); \ std r11,PACA_EX##type+EX_R11(r13); \ + mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \ mfcr r10; /* save CR */ \ + stw r10,PACA_EX##type+EX_CR(r13); /* save old CR in the PACA */ \ DO_KVM intnum,srr1; \ - lbz r11,PACASOFTIRQEN(r13); /* are irqs soft-disabled ? */ \ - cmpwi cr0,r11,0; /* yes -> go out of line */ \ + lbz r10,PACASOFTIRQEN(r13); /* are irqs soft-disabled ? */ \ + cmpwi cr0,r10,0; /* yes -> go out of line */ \ beq masked_interrupt_book3e_##n \ std r1,PACA_EX##type+EX_R1(r13); /* save old r1 in the PACA */ \ - stw r10,PACA_EX##type+EX_CR(r13); /* save old CR in the PACA */ \ - mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \ type##_SET_KSTACK; /* get special stack if necessary */\ andi. r10,r11,MSR_PR; /* save stack pointer */ \ -Mike -- 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
