Hello,
I am doing the same thing, I will try to explain in a brief way, assuming that you are typing on the UART with "-serial stdio" :
qemu init -> kvm_run ioctl -> guest entry -> CPU RUNNING GUEST
Type keyboard -> inside qemu-char.c, typed character is inputted into pl011 FIFO -> RX irq generated ->
RX irq get sent via IRQ_LINE ioctl -> injected into VGIC -> Guest driver -> Guest Driver read into UART's mmio generating
trap -> exit guest into kvm -> io_mem_abort() in arch/arm/kvm/mmio.c -> exit from kvm_run ioctl and go to qemu ->
qemu emulates pl011, returning character to be read -> qemu step in the kvm_run loop executing kvm_run ioctl ->
go back to kvm run loop -> handle the read character -> go back into guest ..
Basically, every mmio access guest will trap into kvm, then kvm will let qemu emulate the device.
You can start from kvm_run loop if I were you.
Isa
On Fri, Jan 24, 2014 at 1:27 AM, 현우박 <jisjang1@xxxxxxxxx> wrote:
Thank you, have a good day!I need to study the whole process of hardware events delivery to guest vm based on source code level. Pls give me a hint where I can start with...(I checked kvm/vgic.c file, and found saying "pending interrupts are stored on the vgic.irq_state vgic bitmap. However , this seems that the hardware events are already set in guest vm's VCPU, I want to know the start point of the hardware events such as keyboard typing and mouse clicking are delivered to guest vm.)Can somebody briefly explain the control flow when keyboard typing events happen on guest VM? I think it might be "Hardware event generated --> KVM injects keyboard events to Guest VM", am I right? Or is the event delivered to the guest vm directly without KVM intervention?Hello,
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
_______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
