On Mon, Feb 25, 2013 at 07:40:07PM +0200, Gleb Natapov wrote: > On Mon, Feb 25, 2013 at 11:17:39AM -0300, Marcelo Tosatti wrote: > > On Mon, Feb 25, 2013 at 11:00:21AM -0300, Marcelo Tosatti wrote: > > > > I see a couple of possible solutions: > > > > 1. Do what Avi said. Make KVM_IRQ_LINE_STATUS be synchronous. Cons: > > > > current QEMU uses KVM_IRQ_LINE_STATUS always and it means that it > > > > will be slow on newer kernels > > > > > > Can add a capability to QEMU and enable APICv selectively only > > > in newer QEMU, which can issue KVM_IRQ_LINE_STATUS on target vcpu > > > only when necessary (and KVM_IRQ_LINE otherwise). > > > > Bad idea. What happens with mixed scenarios. > > > Exactly. > > > > Even a lock serializing injection is not safe because ON bit is cleared > > > before XCHG(PIR, 0). Must do something heavier (such as running on > > > target vcpu context). > > > > Note always running on target vcpu is likely to be slower than no-APICv. > > > Yes, but we will do it only for RTC interrupt. Still performance hit > should be very visible when RTC is in 1000Hz mode. So older qemu-kvm on APICv enabled hardware becomes slow? If that is acceptable, fine. > > So need to do something heavier on the kernel under serialization, if > > firmware cannot be changed (injection from simultaneous CPUs should be > > rare so if data to serialize __accept_apic_irq is cache-line aligned > > it should reduce performance impact). > > > > > > 2. Make KVM_IRQ_LINE_STATUS report coalescing only when vcpu is not > > > > running during injection. This assumes that if vcpu is running and does > > > > not process interrupt it is guest fault and the same can happen on real > > > > HW too. Coalescing when vcpu is not running though is the result of CPU > > > > overcommit and should be reported. Cons interface definition is kind of > > > > murky. > > > > 3. Do not report KVM_IRQ_LINE_STATUS capability and move RTC to use EOI > > > > notifiers for interrupt reinjection. This requires us to add interface > > > > for reporting EOI to userspace. This is not in the scope of this > > > > patchset. Cons: need to introduce new interface (and the one that will > > > > not work on AMD BTW) > > > > Is there no int-ack notification at RTC HW level? > There is, but Windows calls it twice for each injected interrupt. I > tried to use it in the past to detect interrupt coalescing, but this > double ack prevented me from doing so. May be revisit this approach with > willingness to be more hacky about it. Also it is possible to disable > RTC ack for HyperV guests. We do not do it and if we will use the ack we > will not be able to. Is it OK to kill the ability to have coalesced information? > > > Breaks older userspace? > Older userspace will have timedrif with Windows, yes. Note that we some > version of Windows it has it now too. > > > > Other ideas? > > > > > > Can HW write a 'finished' bit after 6 in the reserved area? Suppose its > > > not a KVM-specific problem? > > > > I still think adding locking just to obtain correct injection status is bad > trade-off even if HW would allow us to get away with it. Perhaps with notification at end of copy it could be lockless. With the current scheme, it is not possible to get it right because the notification bit disappears temporarily from sight. And it is not possible to distinguish between 'interrupt injected' and 'interrupt merged', as discussed here. So would have to serialize completly along the lines of: Lock and only inject if can identify that interrupt handler is not running. If its possible to drop KVM_IRQ_LINE_STATUS, then demand APICv HW to use recent software, fine (did not grasp Avi's second idea). -- 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
