From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39418 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYF5m-0005eJ-UI for qemu-devel@nongnu.org; Mon, 12 Jul 2010 05:14:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYF5l-00033f-Gm for qemu-devel@nongnu.org; Mon, 12 Jul 2010 05:14:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26443) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYF5l-00033W-84 for qemu-devel@nongnu.org; Mon, 12 Jul 2010 05:14:25 -0400 Message-ID: <4C3ADCC1.3010605@redhat.com> Date: Mon, 12 Jul 2010 12:13:37 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20100711180910.20121.93313.stgit@localhost6.localdomain6> <20100711180936.20121.35376.stgit@localhost6.localdomain6> <4C3A09F3.8010304@redhat.com> <1278872784.20397.18.camel@x201> <4C3A0DE3.8010806@redhat.com> <4C3AB728.7050406@redhat.com> <20100712090536.GB31191@redhat.com> In-Reply-To: <20100712090536.GB31191@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC PATCH 4/5] APIC/IOAPIC EOI callback List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: chrisw@redhat.com, kvm@vger.kernel.org, mst@redhat.com, qemu-devel@nongnu.org, Alex Williamson , pugs@cisco.com On 07/12/2010 12:05 PM, Gleb Natapov wrote: > On Mon, Jul 12, 2010 at 09:33:12AM +0300, Avi Kivity wrote: > >> On 07/11/2010 09:30 PM, Avi Kivity wrote: >> >>>> Registering an eventfd for the eoi seems like a reasonable alternative. >>>> >>> I'm worried about that racing (with what?) >>> >> I don't think there's a problem. >> >> First, the EOI message is itself asynchronous. While the write to >> the local APIC is synchronous, effects on the rest of the system are >> effected using an APIC message, which travels asynchronously. >> >> Second, a component that needs timely information doesn't have to >> wait; it can read the eventfd and be sure it has seen all EOIs up to >> now. >> >> > I remember we already discussed the use of eventfd for reporting EOI and > decided against it, but I don't remember why. :( Was it because if we > are going to export EOI to userspace anyway we want to be able to use it > for RTC timedrift fixing and for that we need to know what CPU called > EOI and eventfd can't provide that? > IIRC it was the synchronity argument. But it's bogus: if the RTC wants to know whether an ack occured before it makes some decision, all it has to do is read() the eventfd and find out. Another issue is which cpu issued the ack. I suppose we can have per-vcpu eventfds, though that's ugly. -- error compiling committee.c: too many arguments to function