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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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


-------------------------------------------------------------------------
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