>> New kernel modules for KVM are upcoming soon, these module
>> will need to use hypercalls. Before calling the hypercall function,
>> the kvm_main core module has to make sure it won't get unloaded.
>> So hypercall register/unregister are added.
>>
>> Except that the kernel hypercalls handlers are numberes
>> 0-KVM_NR_HYPERCALLS.
>> All the userspace handlers are above KVM_NR_HYPERCALLS.
>>
>
>But, some hypercalls can be handled either in userspace or in the
>kernel, depending on what modules are loaded. How is that handled?
Well, now it's not supported and it should be.
There are two options:
1. If a kernel handled hypercall is not registered, pass it to userspace
for further handling (although it is in the range
0-KVM_NR_HYPERCALLS).
2. Like '1' but also wave the KVM_NR_HYPERCALLS range.
>
>>
>> +static struct kvm_hypercall hypercalls[KVM_KERNEL_NR_HYPERCALLS];
>> +
>> +static int test_hypercall(struct kvm_vcpu *vcpu, unsigned long
>args[])
>> +{
>> + printk(KERN_DEBUG "%s: hypercall invoked\n", __FUNCTION__);
>> +
>> + return 0;
>> +}
>> +
>> +static struct kvm_hypercall __hypercall_test = {
>> + (unsigned long (*)(struct kvm_vcpu*, unsigned long
>> args[]))test_hypercall,
>> + THIS_MODULE,
>> + __NR_hypercall_test,
>> +};
>>
>
>I think we can live without the test hypercall in production code.
Sure, it was here as an example since I yet to write the kernel
PV backend drivers.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
