> 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?
Actually, no. Should it be needed? The standard behaviour for a SIGALRM handler is that when it returns, it should resume whatever the thread was doing when it got the signal, isn't it? Maybe that doesn't hold true when the thread is in a syscall... However, in the main function, kvm_run() never returns, so it can't really be that there should be a loop around it. Is there some underlying assumption that every time KVM gets interrupted, an interrupt gets injected? At this time, I'm not injecting IRQs, just trying out a couple of ways to organize the code around it all. In case anyone is wondering what I'm actually doing, I'm writing a bunch of device emulations around KVM. So far I've gotten Linux about half-way through its boot sequence, so things are progressing nicely. The only major hurdle left is in fact the IRQ injections.. /James On 12/27/06, Dor Laor <[EMAIL PROTECTED]> wrote: > > >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
