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

Ingo Molnar
2007-01-09T14:22:03Z

* 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
;)