>> 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 behavior 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?
The signal can be ignored but this way you can't differentiate between sigalarm that should inject timer irq and other signals that may reach your process. >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 It's weird that the kvm_run does not return? If you get a signal during kvm_run you should get a EINTR result. Can you send the strace? >underlying assumption that every time KVM gets interrupted, an >interrupt gets injected? In general this is the purpose but there are situations it won't happen, for example: user space injects an irq, the kvm_run is called, and a vmenter is executed. A physical irq arrives before the virq is injected thus causing a vm exit. At that time the kvm_run test is a signal was received for the process or it should loop again. So if a signal was received the virq was not really injected. In this case the read_for_interrupt_injection would be 0 so the user space cannot inject more irq until the previous irq is 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. This is very interesting. Good job :) >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
