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? On Sat, Jun 26, 2010 at 9:06 AM, Balachandar <bala1...@gmail.com> wrote: > Hello, > I am trying to understand the virtio mechanism in linux. I read that the > kick function will notify the host side about the newly published buffers. I > am looking especially at virtio_net.Once a packet is ready for transmission > the kick function is called here. From here i traced the call and i think it > goes to this. From here where does it go? Which code contains the backend > driver of virtio. Where is the code in the hypervisor which this kick will > go to? Thank you... > > Thanks, > Bala > > -- Regards, Peter Teoh -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html