> >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.
It's possible to get a signal in the middle of io.string operation. So you'll get io_window exit just then. > >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 So you use the kvmctl.c? Most of the logic is implemented there by the kvm_run function. >Note that I'm not calling kvm_inject_irq() at all. So how the guest receives the virtual irqs? Do you call your own ioctl(kvm->fd, KVM_INTERRUPT, &intr); ? > >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
