On Wed, Jun 30, 2010 at 10:59 AM, Balachandar <bala1486@xxxxxxxxx> wrote: > On Wed, Jun 30, 2010 at 4:17 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> 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 -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
