Ok, slight revision. I've gotten some sample code mostly working, however, I still get one spurius call to the io_window callback when returning from a signal handler.
The code-path is (roughly) as follows: 1. Guest is in a delay loop waiting for an IRQ 2. Timer expires and a SIGALRM is generated, and its handler called 3. Signal handler returns, and kvm_run() resumes executing 4. io_window callback gets called Note that I'm not calling kvm_inject_irq() at all. It's really no biggie (right now) that the io_window callback gets called, but it isn't an expected behaviour. /James On 12/27/06, Dor Laor <[EMAIL PROTECTED]> wrote: > > >> 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
