From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NurAk-0007SZ-LH for qemu-devel@nongnu.org; Thu, 25 Mar 2010 13:48:46 -0400 Received: from [140.186.70.92] (port=37423 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NurAh-0007MU-3x for qemu-devel@nongnu.org; Thu, 25 Mar 2010 13:48:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NurAf-00059K-Hc for qemu-devel@nongnu.org; Thu, 25 Mar 2010 13:48:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10759) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NurAf-00059G-AC for qemu-devel@nongnu.org; Thu, 25 Mar 2010 13:48:41 -0400 Message-ID: <4BABA1F4.3000801@redhat.com> Date: Thu, 25 Mar 2010 19:48:36 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1269497310-21858-1-git-send-email-cam@cs.ualberta.ca> <4BAB2736.7020202@redhat.com> <8286e4ee1003250950l45cc2883yd4788d20f99ef86c@mail.gmail.com> <4BAB9718.3030808@redhat.com> <8286e4ee1003251035o75fed405j45b60d496afa66b5@mail.gmail.com> In-Reply-To: <8286e4ee1003251035o75fed405j45b60d496afa66b5@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v3 0/2] Inter-VM shared memory PCI device List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cam Macdonell Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 03/25/2010 07:35 PM, Cam Macdonell wrote: > >> Ah, I see. You adjusted for the different behaviours in the driver. >> >> Still I recommend dropping the status register: this allows single-msi and >> PIRQ to behave the same way. Also it is racy, if two guests signal a third, >> they will overwrite each other's status. >> > With shared interrupts with PIRQ without a status register how does a > device know it generated the interrupt? > Right, you need a status register. Just don't add any more information, since MSI cannot carry any data. >> Eventfd values are a counter, not a register. A read() on the other side >> returns the sum of all write()s (or eventfd_signal()s). In the context of >> irqfd it just means the number of interrupts we coalesced. >> >> Multivalue was considered at one time for a different need and rejected. >> Really, to solve the race you need a queue, and that can only be done in >> the shared memory segment using locked instructions. >> > I had a hunch it was probably considered. That explains why irqfd > doesn't have a datamatch field. I guess supporting multiple MSI > vectors with one doorbell per guest isn't possible if one 1 bit of > information can be communicated. > Actually you can have one doorbell supporting multiple vectors and guests, simply divide the data value into two bit fields, one for the vector and one for the guest. A single write gets both values into the host, which can then use datamatch to trigger the correct eventfd (which is wired to an irqfd in another guest). > So, ioeventfd/irqfd restricts MSI to 1 vector between guests. Should > multi-MSI even be supported then in the non-ioeventfd/irq case? > Otherwise ioeventfd/irqfd become more than an implementation detail. > I lost you. Please re-explain. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.