Re: [patch] KVM: add MSR based hypercall API

[Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>]

* Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:

> >well, we can standardize on the 32-bit calling convention: eax, ecx, 
> >edx, ebp, etc. We can do that via the 64-bit asm. So it should be the 
> >same i think - just that a 32-bit guest on a 64-bit host wont be able 
> >to set the high bits of those registers.
> >  
> 
> That uglifies 64-bit at the expense of 32-bit.  I'd prefer it to be 
> the other way round, but it's not really an issue either way.

i can pick whichever is better. If we pick 64-bit's natural register 
order, we at least have the chance to do the entry in assembly and then 
to call the hyper-call table directly? (with a default-not-taken branch 
leading out of this logic to a reshuffle thing if the guest is 32-bit) 

[ We also have the chance to let future hardware do the call for us from 
  a MSR-programmed hypercall table, straight from the VMCALL, after it 
  has verified that RAX is within a pre-defined boundary. ]

so i'd vote for the 64-bit natural register order: return value in rax, 
parameters in: rdi, rsi, rdx, rcx, r8, r9. On 32-bit that would be edi, 
esi, edx, ecx, ebx, ebp - the last two shuffled into VCPU_REGS_R8/R9. 
That's 6 parameters already - should be enough - that's what Linux has 
itself. Whatever else must be passed in should come pointer-passed.

> In any case, it needs to be documented, as other guests may not use 
> gcc or regparm.

yeah. Once we pick one and declare it stable, it's cast into stone - 
wont change, ever.

> >in fact it would probably be more logical to use the standard syscall 
> >order: eax, ebx, ecx, edx, esi, edi, ebp?
> 
> Even better.  It allows more registers and avoids a random gcc 
> dependency.

ok.

> 
> >+#define hypercall1(nr)				\
> >+({						\
> >+	int __ret;				\
> >+						\
> >+	asm (" call hypercall_addr\n"		\
> >+		: "=g" (__ret)			\
> >+		: "eax" (nr)			\
> >+	);					\
> >+	__ret;					\
> >+})
> >  
> shouldn't that be
> 
>  asm ("call hypercall_addr" : "=a"(__ret) : "a"(nr))
> 
> ?

oops, yes. I was already wondering about the bogus return value printout 
;)

	Ingo

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV