From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Questions regarding ivshmem spec Date: Thu, 25 Aug 2011 17:40:31 +0300 Message-ID: <4E565EDF.4080800@redhat.com> References: <1314278954.3692.55.camel@lappy> <4E56556E.1080805@redhat.com> <1314283146.3692.59.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cam , David Evensky , Pekka Enberg , qemu-devel , kvm To: Sasha Levin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37710 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751160Ab1HYOkz (ORCPT ); Thu, 25 Aug 2011 10:40:55 -0400 In-Reply-To: <1314283146.3692.59.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: On 08/25/2011 05:39 PM, Sasha Levin wrote: > On Thu, 2011-08-25 at 17:00 +0300, Avi Kivity wrote: > > On 08/25/2011 04:29 PM, Sasha Levin wrote: > > > 2. The spec describes DOORBELL as an array of DWORDs, when one guest > > > wants to poke a different guest it would write something into the offset > > > of the other guest in the DOORBELL array. > > > Looking at the implementation in QEMU, DOORBELL is one DWORD, when > > > writing to it the upper WORD is the guest id and the lower WORD is the > > > value. > > > What am I missing here? > > > > > > > The spec in qemu.git is accurate. The intent is to use an ioeventfd > > bound into an irqfd so a write into the doorbell injects an interrupt > > directly into the other guest, without going through qemu^Wkvm tool. > > > > But the doorbell is a single DWORD, so if a guest writes to it we'd > still need to figure out which guest/vector he wants to poke from > userspace, no? > > If it was an array of doorbells then yes, we could assign an ioeventfd > to each offset - but now I don't quite see how we can avoid passing > through the userspace. > Use the datamatch facility. We didn't want an array of registers to avoid scaling issues (PIO space is quite small). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwb72-0002mp-KT for qemu-devel@nongnu.org; Thu, 25 Aug 2011 10:40:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qwb71-0004zS-AU for qemu-devel@nongnu.org; Thu, 25 Aug 2011 10:40:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwb70-0004zO-VH for qemu-devel@nongnu.org; Thu, 25 Aug 2011 10:40:55 -0400 Message-ID: <4E565EDF.4080800@redhat.com> Date: Thu, 25 Aug 2011 17:40:31 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1314278954.3692.55.camel@lappy> <4E56556E.1080805@redhat.com> <1314283146.3692.59.camel@lappy> In-Reply-To: <1314283146.3692.59.camel@lappy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Questions regarding ivshmem spec List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sasha Levin Cc: Pekka Enberg , cam , qemu-devel , David Evensky , kvm On 08/25/2011 05:39 PM, Sasha Levin wrote: > On Thu, 2011-08-25 at 17:00 +0300, Avi Kivity wrote: > > On 08/25/2011 04:29 PM, Sasha Levin wrote: > > > 2. The spec describes DOORBELL as an array of DWORDs, when one guest > > > wants to poke a different guest it would write something into the offset > > > of the other guest in the DOORBELL array. > > > Looking at the implementation in QEMU, DOORBELL is one DWORD, when > > > writing to it the upper WORD is the guest id and the lower WORD is the > > > value. > > > What am I missing here? > > > > > > > The spec in qemu.git is accurate. The intent is to use an ioeventfd > > bound into an irqfd so a write into the doorbell injects an interrupt > > directly into the other guest, without going through qemu^Wkvm tool. > > > > But the doorbell is a single DWORD, so if a guest writes to it we'd > still need to figure out which guest/vector he wants to poke from > userspace, no? > > If it was an array of doorbells then yes, we could assign an ioeventfd > to each offset - but now I don't quite see how we can avoid passing > through the userspace. > Use the datamatch facility. We didn't want an array of registers to avoid scaling issues (PIO space is quite small). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.