>Hmm.. > >Okay, so if we look at it from a user-space perspective, >try_push_interrupts will be called before KVM starts to execute, and >post_kvm_run will be called immediately after KVM gets stopped for >some reason (IO,MMIO,etc). > >So, the way to inject IRQs into KVM is still the same, except that it >should be done in the try_push_interrupts callback instead?
In general it is the same. Note that the call that really inject the irq is kvm_inject_irq. The try_push_interrupts has the logic around it. > >On a slightly related note, I'm having a slight problem stopping and >then starting KVM again. >I have a timer go off, generating a SIGALRM, which stops KVM and >enters the signal handler. However, when I return from the signal >handler, KVM tries to start again, but gets stuck in a loop where >handle_io_window gets called in a never ending loop. > >Am I missing a step here? When you're getting the SIGALARM you probably need to mark that an irq needs to be injected. (but not call the kvm ioctls). Don't you have a main loop that runs kvm_run from kvmctl.c for ever? The try_push_interrupts callback needs to read your irq pending variable previously set in the timer handler and call kvm_inject_irq. > >/James > >On 12/27/06, Dor Laor <[EMAIL PROTECTED]> wrote: >> > >> >I've just checked out the latest version of the trunk, and some things >> >have changed... >> > >> >kvm_callbacks has two new functions, >> > >> >try_push_interrupts and post_kvm_run >> > >> >Could someone shine some light on what they should do ? >> >try_push_interrupts gets called immediately as I call kvm_run(), and >> >since I haven't got a handler for it, my code (quite expected) >> >segfaults.. >> >> The latest commit purpose is to improve the interrupt latency + handle >> irq lost situations. >> If the user space / qemu needs to injects interrupt it sets the >> kvm_run->request_interrupt_window variable. If it is also possible to >> inject the interrupt at that time (the >> kvm_run->ready_for_interrupt_injection) the user space/qemu injects the >> pending interrupt. >> >> There are situations were the interrupt window is block by vt/svm or the >> interrupt window was open but a physical irq happened exactly before the >> virq was injected. In that case the virq won't be injected. >> If the request_interrupt_window was set the kvm will go back as quickly >> as possible to the user space when the window opens. >> >> At the end of the kvm_run ioctl the kvm synchronizes the variables that >> effect user space/qemu: the ready_for_interrupt_injection flag, >> cr8(tpr), apic_base and eflags IF bit. The is done instead of the longer >> save_regs version. >> >> Hope it helped :) >> > >> >/James >> > >> >----------------------------------------------------------------------- >> -- >> >Take Surveys. Earn Cash. Influence the Future of IT >> >Join SourceForge.net's Techsay panel and you'll get the chance to share >> >your >> >opinions on IT & business topics through brief surveys - and earn cash >> >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD >> EV >> >_______________________________________________ >> >kvm-devel mailing list >> >[email protected] >> >https://lists.sourceforge.net/lists/listinfo/kvm-devel >> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
