On 06/30/2010 10:02 AM, Balachandar wrote:
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
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
