From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH v4 2/2] KVM: VMX: Add Posted Interrupt supporting Date: Mon, 25 Feb 2013 11:17:39 -0300 Message-ID: <20130225141739.GA26737@amt.cnet> References: <20130224141917.GC4284@redhat.com> <20130224180857.GA10477@amt.cnet> <20130225110159.GA12299@redhat.com> <20130225110702.GA12726@redhat.com> <20130225133419.GH21422@redhat.com> <20130225140021.GC2057@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Zhang, Yang Z" , Avi Kivity , "kvm@vger.kernel.org" , "Zhang, Xiantao" To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50595 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755556Ab3BYOSf (ORCPT ); Mon, 25 Feb 2013 09:18:35 -0500 Content-Disposition: inline In-Reply-To: <20130225140021.GC2057@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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. > 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. 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? > Breaks older userspace? > > > > Other ideas? > > Can HW write a 'finished' bit after 6 in the reserved area? Suppose its > not a KVM-specific problem? >