On 15.05.2010, at 19:30, Avi Kivity wrote: > On 05/15/2010 11:26 AM, Alexander Graf wrote: >> >>> That means you never inject an interrupt from the iothread (or from a >>> different vcpu thread)? >>> >>> If that's the case we might make it part of the API and require the ioctl >>> to be issued from the vcpu thread. We'd still be left with the s390 >>> exception. >>> >> Well I'm not sure that's guaranteed for MOL or Dolphin, but I guess the user >> base is small enough to ignore them. >> >> Either way, I'm actually rather unhappy with the way interrupts work right >> now. We're only injecting interrupts when in the main loop, which is rare if >> we did our homework right. So what I'd really like to see is that the MPIC >> on ppc directly invokes KVM_INTERRUPT to pull (and losen) the interrupt >> line. That way we can't just accidently miss interrupts. >> > > on x86 we signal the vcpu thread to pull it out of the main loop and poll the > apic.
Hrm, makes sense. Though it's additional overhead of a task switch. Why take the burden if you don't have to? > >> What happens now with ppc64 guests that have EE lazily disabled is: >> >> * device in userspace wants to trigger an interrupt >> * mpic pulls external interrupt line >> > > <signal> > >> * kvm_arch_pre_run sees that external interrupt line is pulled, issues >> ioctl(KVM_INTERRUPT), kernel space sets trigger_interrupt=1 >> * we enter the guest >> * we inject an external interrupt, set trigger_interrupt=0 >> * guest gets the interrupt, sees it's lazily disabled, sets msr.ee=0 >> * guest moves on, sets msr.ee=1 again later >> *** guest expects the interrupt to trigger again, but we don't know that >> it's still pending >> > > Why does the guest expect the interrupt to trigger again? Is it level > triggered until acknowledged? IIUC, yes. > That's exactly why x86 has run->request_interrupt_window, > run->ready_for_interrupt_injection, and run->if_flag. So how does x86 userspace get notified when it has an interrupt pending but couldn't inject it? Without a notification, we delay interrupts by quite some time. > >> -> we need to exit to userspace to realize that the interrupt is still >> active >> >> This is fundamentally broken. What I'd like to see is: >> >> * device in userspace wants to trigger an interrupt >> * mpic pulls external interrupt line, automatically issues >> ioctl(KVM_INTERRUPT) >> * we enter the guest >> * we inject the external interrupt >> * guest gets the interrupt, sees it's lazily disabled, sets msr.ee=0 >> * guest moves on, sets msr.ee=1 again later >> * we inject the external interrupt again, since it's still active >> * guest acknowledges the interrupt with the mpic, issues >> ioctl(KVM_INTERRUPT, disable) >> -> all is great >> > > This is similar to KVM_IRQ_LINE. Well, KVM_IRQ_LINE would be the in-kernel pic, no? That'd mean I'd have to reimplement the mpic in kernel space - which might eventually be a good idea when going for SMP, but I'd first like to see if I can keep the current interrupt injection path efficient. > >> For that to work we need to enable triggering KVM_INTERRUPT from a non-vcpu >> thread. >> > > KVM_IRQ_LINE is a vm ioctl instead of a vcpu ioctl. > > The motivation for the strict 'issue vcpu ioctls from vcpu thread' rule is to > prepare the way for a syscall (instead of ioctl) API. Then we lost the fd > argument, and choosing the vcpu is done by associating it with the current > task. That allows us to get rid of vcpu->mutex and fget_light() (as well as > the ioctl dispatch). If we define the API to only work on the current vcpu with a few excetions where we're safe (KVM_INTERRUPT), that'd get rid of the mutex too, no? What does fget_light do? And does the ioctl dispatch cost that much? I like the flexibility of it to be honest. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
