[RFC] New hcall mechanism Was: [PATCH 0/3] powerpc: Instrument Hypervisor Calls

[Jimi Xenidis]

Looking at this patch set, it reminds me how IMNSHO the plpar calling  
mechanism in Linux are a little arcane.
When we were writing "toy" OSes for hypervisors we had the following  
assembly:

### NOTE: this code does not accommodate passing args in r11 & r12  
(arg 8 and 9),
### and 'in' could be used to streamline the fetching of r11 & r12  
from the stack where the ABI has placed them.
#define PAPR(in, out, name, func_code)	\
	_GLOBAL(name);	 		\
         /* profiling code here */		\
	std r3,-GPR_WIDTH(r1); 		\
	li r3,func_code; 		\
	HSC;				\
         /* profiling code here */		\
	ld r12,-GPR_WIDTH(r1);		\
	cmpi 0,r12,0;			\
         bne ret	## out;	/* only store regs if r12 != NULL,  
indicating the caller does not care about the return value */ \
	b ret0

ret7:	std r10, 6 * GPR_WIDTH(r12)
ret6:	std r9, 5 * GPR_WIDTH(r12)
ret5:	std r8, 4 * GPR_WIDTH(r12)
ret4:	std r7, 3 * GPR_WIDTH(r12)
ret3:	std r6, 2 * GPR_WIDTH(r12)
ret2:	std r5, 1 * GPR_WIDTH(r12)
ret1:	std r4, 0 * GPR_WIDTH(r12)
	nop
ret0:	blr
	
PAPR(4, 1,papr_enter, H_ENTER)
...

This allowes for the C interface for H_ENTER to be:
   long papr_enter(ulong *slot, ulong flags, ulong hpte_group, ulong  
hpte_v, ulong hpte_r);

making the call:
   ulong slot;
   lapr_rc = papr_enter(&slot, flags, hpte_group, hpte_v, hpte_r);
Rather than:
   ulong slot, dummy0, dummy1;
   lpar_rc = plpar_hcall(H_ENTER, flags, hpte_group, hpte_v, hpte_r,  
&slot, &dummy0, &dummy1);

The latter saving pointers to stack variables on the stack before the  
call.

A mechanism such as this could also make the profiling far simpler  
and efficient as the profiling code get generated by the PAPR() macro  
above.
I is also possible to generate the prototypes from the PAPR()  
statements above.


Comments welcome?
-JX

On Jun 13, 2006, at 11:47 PM, Mike Kravetz wrote:

> This patch series adds instrumentation to Hypervisor calls.  Code and
> ideas were taken from the patch set provided by Christopher Yeoh.
>
> The idea is to put all instrumentation code behind a configuration
> option so that it can easily be added/removed.  The instrumentation
> code is kept to a minimum in the hopes that it's impact to performance
> will not be noticed.  Statistics are made available via files in  
> sysfs.
>
> -- 
> Mike
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev