On 16.05.2010, at 10:23, Avi Kivity wrote: > On 05/16/2010 04:00 AM, Alexander Graf wrote: >> 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? >> > > That's what the world looked like in 2006. > > We could change it, but there's not much point, since having the local apic > in the kernel is pretty much a requirement for reasonable performance.
Well, I'm not convinced yet that's the case for PPC as well. The timer is in-cpu anyways and I don't see why IPIs should be slow with a userspace pic - if we keep the overhead low. So let me think this through. With remote interrupt injection we have. * thread 1 does vcpu_run * thread 2 triggers KVM_INTERRUPT on fd * thread 2 signals thread 1 so we're sure the interrupt gets injected * thread 1 exits into qemu * thread 1 goes back into the vcpu, triggering an interrupt Without we have: * thread 1 does vcpu_run * thread 2 wants to trigger an an interrupt, sets the qemu internal bit * thread 2 signals thread 1 so we're sure the interrupt gets processed * thread 1 exits into qemu * thread 1 triggers KVM_INTERRUPT on fd * thread 1 goes into the vcpu So we don't really buy anything from doing the remote injection. Hrm. What's somewhat striking me here though is - why do we need KVM_INTERRUPT when there's all those kvm_run fields? Can't we just do interrupt injection by setting run->trigger_interrupt? There's only a single "interrupt line" on the CPU anyways. That way we'd save the ioctl and get rid of the locking problem altogether. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
