>Let me see if I understand your question properly; you are running a KVM >virtual CPU which executes WFI in the guest, and then you are not >receiving >interrupts in the guest nor getting events back from KVM which you somehow use >to run a backend simulation in userspace?
You are right! >KVM/Arm can do two things for WFI: > 2. Trap WFI to KVM. KVM asks Linux to schedule another process until > there's a virtual interrupt for the VCPU. This is what mainline > KVM/Arm does. > > >I suspect what's happening is that you are using a normal kernel configured as >(2), and therefore you only count cycles for the perf event while the >guest >runs the timer ISR which obviously is much much less than if you had a >constant running VCPU. Am I on the right track? Yes. The only thing which is somewhat strange is that I am using a userspace interrupt controller so my timer interrupt goes its way from the kvm virtual timer into userspace via KVM_ARM_DEV_EL1_VTIMER, through the userspace interrupt controller and back into kvm via KVM_IRQ_LINE. This of course means, that as long the vcpu is executing and has not exited to userspace there is no interrupt delivery and thus no timer interrupt service routine. Nevertheless, the counting mechanism increases slowly and eventually the kvm_cpu exits to userspace enabling me to deliver timer/uart interrupts. This leads to a very slow simulation, once linux is completely booted and interrupt-driven. But that just as a sidenote. >Second, and possibly preferred, you can hook up your simulation event to a >timer event in the case of trapping on a WFI. See kvm_handle_wfx() in >>arch/arm64/kvm/handle_exit.c and follow kvm_vcpu_block() from there to see >how KVM/Arm handles this event. That sound like a great plan. I basically want to achieve the following: instead of waiting inside kvm_vcpu_block() for a virtual interrupt I want to exit to userspace and signal that the virtual cpu is waiting for a interrupt. Then I can react inside my simulation via a uart/timer interrupt and enter the guest again. Thanks four your ideas, they gave me a really good starting point. There is still one thing I do not understand: In the documentation of the kvm api there is the the 'request_interrupt_window' flag in the kvm_run structure. This is a request that kvm_returns when it becomes possible to inject interrupts. This looked as the thing I want to do/use but did not gave the expected result. Is this flag disabled on kvm/arm? Thanks again, Jan _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
