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? Thanks, Bala -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
