From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2] Shared memory device with interrupt support Date: Mon, 18 May 2009 14:38:39 +0300 Message-ID: <4A1148BF.6060902@redhat.com> References: <3D9CB4061D1EB3408D4A0B910433453C030BCA8892@inbmail01.lsi.com> <5A459472-C496-49ED-93D8-0C4CC391F50A@cs.ualberta.ca> <4A1086E6.30405@redhat.com> <4A114281.3070209@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cam Macdonell , "Kumar, Venkat" , "kvm@vger.kernel.org list" To: Gregory Haskins Return-path: Received: from mx2.redhat.com ([66.187.237.31]:39020 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755415AbZERLio (ORCPT ); Mon, 18 May 2009 07:38:44 -0400 In-Reply-To: <4A114281.3070209@novell.com> Sender: kvm-owner@vger.kernel.org List-ID: Gregory Haskins wrote: > I'll just add that you could tie the irqfd to an iosignalfd to eliminate > the involvement of qemu on either side as well. I'm not sure if that > really works with the design of this particular device (e.g. perhaps > qemu is needed for other reasons besides signaling), but it is a neat > demonstration of the flexibility of the newly emerging kvm-eventfd > interfaces. > If we have an iosignalfd for point-to-point (say, a pio port with the guest ID) we can do direct guest-to-guest signalling. For broadcast or multicast, we need to exit to qemu to handle the loop. -- error compiling committee.c: too many arguments to function