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

Avi Kivity
2007-01-09T13:41:36Z

Ingo Molnar wrote:
> * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>
>
>>>> Where is the vmcall exit handler?
>>>>
>>>>
>>> in my tree, have not sent the patch yet - first want to combine it
>>> with the cr3 feature to have it tested.
>>>
>>>
>> I'd like it in the final patch.
>>
>
> yeah. Right now i have:
>
> patches/kvm-paravirt-host.patch
> patches/kvm-paravirt-guest.patch
> patches/kvm-paravirt-hypercall-host.patch
> patches/kvm-paravirt-hypercall-guest.patch
> patches/kvm-paravirt-cr3-cache.patch
>
> this builds and boots fine on VMX, and a test-hypercall is successfully
> issued. I've attached a tarball of them.
>
> i've changed the details you mentioned (printk loglevels, etc.), and
> some other detail as well: the ->patch_hypercall() thing now patches in
> the 'ret' instruction as well. This allowed me to add a -ENOSYS default
> entry there, to have defined error behavior in case the hypervisor does
> not patch things.
>
> NOTE: i have not updated the cr3 patch to the hypercall API yet (hence
> the aliasing bug is not fixed yet), i wanted to get this to you so that
> we can think about the hypercall API.
>
> Right now what i have is only good to test that the VMCALL instruction
> works - but the API must look differently. I'd prefer a register-based
> thing so that i can embedd hypercalls within Linux without having to go
> to a wrapper function. Right now a "call hypercall_addr" is a
> regparm-based function entry. I'd like to keep that - but not have a
> fixed number of parameters but inlines/macros for all parameter
> combinations: 1, 2, 3, 4, 5 param, picked up automatically via use. I.e.
> a 2-param call would be:
>
> hypercall(KVM_cr3_miss, cr3);
>
> a 3-param call would be:
>
> hypercall(KVM_api_call1, param1, param2);
>
> a 1-param call would be:
>
> hypercall(KVM_api_call2);
>
> Does this look good to you? I'd like the basic API to be as light as
> possible.
>
>

Won't 32-bit and 64-bit pick different registers?

We can work around it (call is_long_mode() when decoding the hypercall),
but it kind of defeats the purpose of the optimization, no?

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