From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v3 0/2] Inter-VM shared memory PCI device Date: Thu, 25 Mar 2010 19:48:36 +0200 Message-ID: <4BABA1F4.3000801@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org To: Cam Macdonell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:14685 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751488Ab0CYRsl (ORCPT ); Thu, 25 Mar 2010 13:48:41 -0400 In-Reply-To: <8286e4ee1003251035o75fed405j45b60d496afa66b5@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.