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