Re: Where is the entry of hypercalls in kvm?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux