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

Avi Kivity
2007-01-09T14:35:02Z

Ingo Molnar wrote:
> * 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.
>
>

Agreed, let's make it so. When you say "pointer-passed" you mean
physical address passed, right? ;-)

--
error compiling committee.c: too many arguments to function