Re: Where is the entry of hypercalls in kvm?

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/30/2010 10:02 AM, Balachandar wrote:
> On Wed, Jun 30, 2010 at 10:59 AM, Balachandar<bala1486@gmail.com>  wrote:
>    
>> On Wed, Jun 30, 2010 at 4:17 AM, Peter Teoh<htmldeveloper@gmail.com>  wrote:
>>      
>>> Your questioned is answered here:
>>>
>>> http://www.spinics.net/lists/kvm/msg37526.html
>>>
>>> And check this paper out:
>>>
>>> http://ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf
>>>
>>> The general concept to remember is that QEMU and KVM just execute the
>>> input as binary stream....it does not know what "functions" it is
>>> executing...so the binary stream can be any OS (windows / Linux
>>> etc)....QEMU just setup the basic block (call basic blocks
>>> translation) mechanism, and then execute it block by block.   Each
>>> block by definition is demarcated by a branch/jump etc.   Within the
>>> block if there is any privilege instruction, (eg, write MSR registers,
>>> load LDT registers etc), then a transition will be made from guest in
>>> QEMU into KVM to update the VMCB/VMCS information.   (these terms are
>>> from Intel/AMD manual).
>>>
>>> I have not seen any IOCTL calls in QEMU, but I suspect ultimately it
>>> should drop to a VMRUN (for AMD, Intel called it VMLAUNCH or VMRESUME)
>>> calls inside KVM, which can be found here:
>>>
>>> arch/x86/kvm/
>>>
>>> And the AMD specific virtualization is done in svm.c whereas that of
>>> vmx.c is for Intel.
>>>
>>> Copying the remark in vmx.c:
>>>
>>> /*
>>>   * The exit handlers return 1 if the exit was handled fully and guest execution
>>>   * may resume.  Otherwise they set the kvm_run parameter to indicate what needs
>>>   * to be done to userspace and return 0.
>>>   */
>>> static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = {
>>>         [EXIT_REASON_EXCEPTION_
>>>
>>> And after reading the Intel manual, u will understand that "exit" here
>>> actually refers to the special set of privilege intel instructions,
>>> which upon being executed by the guest OS, will immediately caused and
>>> VMEXIT condition, and these are handled by the above handler in
>>> kvm.ko.
>>>
>>> To know the entry point INTO the guest OS (ie, when the guest code
>>> will first be run) first must understand that all these VMX operation
>>> are a state machine (3, VMLAUNCH, VMRESUME and VMEXIT).   Once inside
>>> the VMRESUME state, there is no way for it to access any of the hosts
>>> resources, only accessible after VMEXIT is triggered.
>>>
>>> All key APIs are defined here (for Intel) (this is KVM specific, Xen
>>> has another mechanism, :
>>>
>>> static struct kvm_x86_ops vmx_x86_ops = {
>>>         .cpu_has_kvm_support = cpu_has_kvm_support,
>>>         .disabled_by_bios = vmx_disabled_by_bios,
>>>         .hardware_setup = hardware_setup,
>>>         .hardware_unsetup = hardware_unsetup,
>>> ...
>>>         .run = vmx_vcpu_run,
>>>         .handle_exit = vmx_handle_exit,
>>>         .skip_emulated_instruction = skip_emulated_instruction,
>>>         .set_interrupt_shadow = vmx_set_interrupt_shadow,
>>>
>>> and vmx_vcpu_run() is the the answer to your question.....i supposed?
>>>
>>> Perhaps another summary resource:
>>>
>>> http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05015_WinHEC05.ppt
>>>
>>> As for virtio_net.....it is implemented in
>>> drivers/net/virtio_net.c......not sure what is your question?
>>>
>>>        
>> Thank you for your elaborate answer. My question is what is the code
>> in qemu-kvm that is called when kick function is called in virtio_net?
>> The kick function does some ioport write and this will be trapped by
>> the hypervisor into kvm. Then kvm will call some function in qemu-kvm
>> userspace for io emulation. So for this particular case virtio_net
>> what is the function in qemu-kvm that will be called when kick is
>> encountered in the guest?
>>
>>      
> I already got the answer from Alexander. If anyone is looking the
> function is virtio_net_write in hw/virtio_pci.c
>    

virtio_ioport_write() in hw/virtio_pci.c.  It eventually goes to 
virtio_net_handle_tx, virtio_net_handle_rx, or virtio_net_handle_ctrl 
depending on which queue is being notified.

Regards,

Anthony Liguori

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>