just to clarify further. On Wed, Jun 30, 2010 at 11:10 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: > On 06/30/2010 03:56 AM, Alexander Graf wrote: >> >> On 30.06.2010, at 10:17, Peter Teoh 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). >>> >> >> Eh, no. >> >> There are two modes of operation: >> >> 1) TCG >> 2) KVM >> >> In mode 1, qemu goes through target-xxx/translate.c and converts the basic >> blocks you were talking about above to native machine code on the host >> system using tcg (see the tcg directory). No KVM is involved, everything >> happens in user mode. >> >> In mode 2, qemu executes _everything_ by calling KVM. There is no guest >> code interpreted, looked at or whatever in qemu. > > Only because there is a mini-x86 interpreter in the kernel. That lets KVM > expose an idealized interface to qemu that requires no instruction > interpretation. > >From the ioctl call in QEMU, the following will be called: int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) { int r; sigset_t sigsaved; and then subsequently: r = emulate_instruction(vcpu, vcpu->arch.mmio_fault_cr2, 0, EMULTYPE_NO_DECODE); which will interpret the x86 bytecode, correct? So does it distinguish between ring0 vs ring3 insn? > More to the point of the original question, virtio is typically implemented > on top of an emulated PCI device. The kick operation is implemented as a > write to a PCI IO region that's mapped to PIO. If you look at > hw/virtio-pci.c, you'll see the entry points. > > Regards, > > Anthony Liguori > >> Whenever the guest CPU runs, it runs because qemu called ioctrl(VCPU_RUN) >> on its kvm vcpu fd. >> >> >>> >>> I have not seen any IOCTL calls in QEMU, >>> >> >> See kvm*.c and target-xxx/kvm.c >> >> >>> >>> 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. >>> >> >> in kvm-xxx.ko for x86. >> >> Also, please don't top post :) >> >> >> Alex >> >> -- >> 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 >> > > -- Regards, Peter Teoh -- 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
