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-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
