Re: Where is the entry of hypercalls in kvm?

Peter Teoh
2010-06-30T16:36:27Z

just to clarify further.

On Wed, Jun 30, 2010 at 11:10 PM, Anthony Liguori <anthony@codemonkey.ws> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>

--
Regards,
Peter Teoh